You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The user gets a new phone.
How can we ensure, that the user easily gets a new token onto this phone?
Copying the existing token is a bad idea, since the old phone would be possibly passed to the grandson.
So we could provide an easy way to enrolling a new token (well, actually this exists as "token rollover", if the old phone still exists...)
If we had the phone number, we could send a rollout link via SMS, if the user previously opted in for phone-change...
Give back the existing token. On the old phone the user could "give back the token to the server" and thus someway get a voucher to rollout the token on a new phone...
If we would do an export with a QR code chuckle, we should only be allowed to do the export once. And maybe also check on the old phone the valid OTP value from the new phone.
However, I think there are two differences:
A mechnism that works, if the old phone still exists (then the user could also enroll a new token or roll-over)
A mechinsm that works, when the old phone is already dumped.
I think the 2nd scenario is the challenging one which also will occur often!
The text was updated successfully, but these errors were encountered:
I would like to add that push token (the private key) can not be exported. So if we were to restore the "same" token on a new phone, push token have to be enrolled new.
The user gets a new phone.
How can we ensure, that the user easily gets a new token onto this phone?
Copying the existing token is a bad idea, since the old phone would be possibly passed to the grandson.
So we could provide an easy way to enrolling a new token (well, actually this exists as "token rollover", if the old phone still exists...)
If we had the phone number, we could send a rollout link via SMS, if the user previously opted in for phone-change...
Give back the existing token. On the old phone the user could "give back the token to the server" and thus someway get a voucher to rollout the token on a new phone...
If we would do an export with a QR code chuckle, we should only be allowed to do the export once. And maybe also check on the old phone the valid OTP value from the new phone.
However, I think there are two differences:
I think the 2nd scenario is the challenging one which also will occur often!
The text was updated successfully, but these errors were encountered: