for example, SMS-based 2FA doesn't work when you travel abroad
WiFi calling usually also supports texts over wifi.
then generates a signed authentication request using the stored private key, then sends that request to the relying party's auth server, which authenticates the user by verifying the signature using the public key it received during registration
so as a customer, I need to keep track of all public keys of my customers?
Key backup and recovery is handled automatically via the cloud (iCloud / Google Drive)
So in case I get access to a Gmail account, I can get full access to the customers account. Is the key protected by passphrases?
WiFi calling usually also supports texts over wifi.
True, but WiFi calling remains opt-in for most carriers (and I suspect it'll remain so given the incentives in play). I don't have stats on WiFi calling adoption, but anecdotally, most people I've asked (including my cofounder), have been SOL when traveling abroad and relying on SMS OTP
so as a customer, I need to keep track of all public keys of my customers?
You only need to keep track of the one public key that your user generated for your service, no different than keeping track of their password. It's arguably easier to keep track of a public key than a password given you don't absolutely have to hash+salt a public key.
So in case I get access to a Gmail account, I can get full access to the customers account.
Yes, if you manage to break in to a Google or Apple account (which is a lot harder than breaking into an account at just about any other company), you would get access to an individual's private keys, same as you would get access to all of their stored passwords, email OTP, email password recovery, text messages, photos, OIDC-connected accounts, etc.
Is the key protected by passphrases?
Yes, developers can enable securing the keys with a user-set 4-digit PIN that the user must input upon key recovery. This is optional for developers.
Yes, when developers enable passcode protection, the guess rate limiting is based on the OS default because it's accessing the same subsystem responsible for unlocking the phone itself.
so as a customer, I need to keep track of all public keys of my customers?
Yes. You probably want a reasonable limit. A customer might have ten phones, but if they have a hundred phones they already know they're a weirdo and you won't be the first one to tell them that. You will probably also want to have a way for customers to distinguish one from another, so that they can say "Oh I gave my old iPhone to my brother" and delete the unneeded credentials.
The good news is that as their name might suggest, they're not secrets, so now you don't need to worry about anybody stealing them. If Keyri did even a halfway competent job of this they're useless to anybody except you.
Comments
WiFi calling usually also supports texts over wifi.
so as a customer, I need to keep track of all public keys of my customers?
So in case I get access to a Gmail account, I can get full access to the customers account. Is the key protected by passphrases?
True, but WiFi calling remains opt-in for most carriers (and I suspect it'll remain so given the incentives in play). I don't have stats on WiFi calling adoption, but anecdotally, most people I've asked (including my cofounder), have been SOL when traveling abroad and relying on SMS OTP
You only need to keep track of the one public key that your user generated for your service, no different than keeping track of their password. It's arguably easier to keep track of a public key than a password given you don't absolutely have to hash+salt a public key.
Yes, if you manage to break in to a Google or Apple account (which is a lot harder than breaking into an account at just about any other company), you would get access to an individual's private keys, same as you would get access to all of their stored passwords, email OTP, email password recovery, text messages, photos, OIDC-connected accounts, etc.
Yes, developers can enable securing the keys with a user-set 4-digit PIN that the user must input upon key recovery. This is optional for developers.
Is this rate limited by the phone for access to the secret key?
Yes, when developers enable passcode protection, the guess rate limiting is based on the OS default because it's accessing the same subsystem responsible for unlocking the phone itself.
Yes. You probably want a reasonable limit. A customer might have ten phones, but if they have a hundred phones they already know they're a weirdo and you won't be the first one to tell them that. You will probably also want to have a way for customers to distinguish one from another, so that they can say "Oh I gave my old iPhone to my brother" and delete the unneeded credentials.
The good news is that as their name might suggest, they're not secrets, so now you don't need to worry about anybody stealing them. If Keyri did even a halfway competent job of this they're useless to anybody except you.