4 ms·

I actually hate this, because now I need to install a bunch of apps, 1 per service, just for 2FA. Even if I don’t use them. I much rather prefer Google authenti

I actually hate this, because now I need to install a bunch of apps, 1 per service, just for 2FA. Even if I don’t use them. I much rather prefer Google authenticator, personally. Having an extra option is nice though. But it’s often one or the other.

scrollaway 6y ago
Agreed. It's not a bother when you already have the app, so for Wise i don't mind so much, but it is annoying. And since I use my password manager as my 2fa app, i have a degraded user experience when logging in to it compared to using 1Password. (I'm aware of the implications, don't need a lecture)
tialaramex 6y ago
If they do WebAuthn they can basically authenticate web visitors and app users via the same approach. A modern iPhone or high end Android both offer the same API where you can get the phone to give your app effectively proof this is the same phone that previously enrolled being used by the same person. Did the phone decide that by examining their fingerprint, video of their face, a blood sample? - you don't know, but it assures you it verified the user and it's definitely the same phone your user used to enroll. You may notice this is the same feature as WebAuthn and is driven by the same technology. If you have server backend code for WebAuthn, the scenario for an app is essentially the same except, where you need your site's domain name for WebAuthn, these iOS/Android APIs need you to do a little bit of work in your app development cycle, get an ID out of that which is effectively unique for your app, and stick that ID into your backend code where the domain name goes. So, users cannot enroll once and have it work both in the app and on a web login, because if that could work an iOS or Android app could exist that just gives bad guys all your WebAuthn credentials - but if your users only do one or the other, they don't care, and either will work with only a small tweak to your backend. If you have users who have the app but don't realise your web site isn't the app, I believe there are already mechanisms to "help" them get where they should be.

scrollaway 6y ago

Agreed. It's not a bother when you already have the app, so for Wise i don't mind so much, but it is annoying. And since I use my password manager as my 2fa app, i have a degraded user experience when logging in to it compared to using 1Password. (I'm aware of the implications, don't need a lecture)

tialaramex 6y ago

If they do WebAuthn they can basically authenticate web visitors and app users via the same approach. A modern iPhone or high end Android both offer the same API where you can get the phone to give your app effectively proof this is the same phone that previously enrolled being used by the same person. Did the phone decide that by examining their fingerprint, video of their face, a blood sample? - you don't know, but it assures you it verified the user and it's definitely the same phone your user used to enroll. You may notice this is the same feature as WebAuthn and is driven by the same technology. If you have server backend code for WebAuthn, the scenario for an app is essentially the same except, where you need your site's domain name for WebAuthn, these iOS/Android APIs need you to do a little bit of work in your app development cycle, get an ID out of that which is effectively unique for your app, and stick that ID into your backend code where the domain name goes. So, users cannot enroll once and have it work both in the app and on a web login, because if that could work an iOS or Android app could exist that just gives bad guys all your WebAuthn credentials - but if your users only do one or the other, they don't care, and either will work with only a small tweak to your backend. If you have users who have the app but don't realise your web site isn't the app, I believe there are already mechanisms to "help" them get where they should be.