This seem to negate the whole purpose of 2FA - now your second factor becomes "something you know" instead of "something you have".
What I really want (and would consider a "missing authenticator app") is an app that stays on the phone and keeps all keys there with a client companion app for desktop that communicates with the mobile via Bluetooth to automatically fill the 2FA codes.
I looked into the app a little bit and a few things I see that set it apart from the ones I'm familiar with:
- Sync is optional: it is a premium ($4.99/yr) feature that is not enabled by default. Other tools I've used have iCloud sync turned on by default.
- Auto-lock: you can set a password so that some guest user who might be using your computer can't just open and copy your codes.
- Backup code storage: you can store the backup keys in the app. (Kinda strange, since if you have access to the backup codes, you also have access to the OTP itself so /shrug/).
- Keys are availabe: most of the apps I've used do not allow you to see the key after creating the account, but this does.
Whether these are good or desirable features, they are somewhat distinct from the apps I've used.
What’s the missing piece compared to Authenticator Plus or Authy? What’d be my actual missing piece would be backups to my own infra, rather than iCloud or any other third party.
To me, backups are something you don't want for 2FA. It just turns your second factor into an unergonomic first factor. What you want is the ability to enroll multiple authenticators. Newer standards like WebAuthn make this trivial -- for accounts I have that support WebAuthn, I have a portable security key on my keychain, a "permanent" key on my workstation, Windows Hello, and FaceID that can all be used to log in. If I lose one of those devices, I just use another method to log in (and revoke that credential, of course!) and it's no problem at all.
I think what is killing adoption here is the reliance of so many third-parties on Google Authenticator style OTPs. OTPs are terrible -- you completely lose 2FA if you lose your phone, and OTPs are easily phished. I don't know why it's so popular, whether it's some regulation, or whether people just wrote their 2FA code a decade ago and haven't updated their flow to accommodate newer standards. Whatever the reason, it is just driving people to develop and use cloud-based password managers and OTP syncers like this, and those things aren't helping security. They're giving people a false sense of security; they feel like they are as protected as having a physical token required for all logins to important apps, but without any of the protection. It's less than ideal.
Most services with OTP use "backup codes", which you are supposed to back up securely. Now, what's the difference to backing up the actual OTP "seed" or how is it called -- either by saving the original QR code, or a built-in backup functionality in the authenticator? Back-up codes give you the ability to log in and disable 2FA, which makes them as powerful as the actual authenticator.
OTP is bad, as you pointed out, but backing up the seed does not make it worse.
I admit I use Aegis because of the backup functionality. (Well, also for the support for Steam...) After using Google Authenticator, losing my phone and having to use backup codes and painfully re-enable 2FA on all my accounts, I realized that using an authenticator with backup is much simpler than the backup codes.
Yeah, you're right. The backup codes are a big pain, and kill the security of the account. (Like many others, I don't print those out... they're just in my password manager.) OTP backup is no less secure than that, and is a strong usability improvement.
Things would be way better if people just implemented WebAuthn, though. It's more secure than OTPs, and it's so transparent and easy to use that people think it's less secure. Passwords and OTPs should go away, and it's only a few lines of Javascript to make them go away. Sigh!
I agree with you, but we live in a world where we need to be grateful for webpages that use standards-based OTP, and don't see 2FA as just another opportunity to make you install their mobile app. (Looking at Steam and many others...) WebAuthn is wayyy too much to ask nowadays.
The UI of Authy on the Mac is terrible. One of the worst examples of adapting a mobile UI to a mouse+windows interface I’ve ever seen. Also not native. And its iPhone interface isn’t particularly good in the first place.
Backups to own infra has already been taken care of years ago. Look at OTP Auth[1] for example. That will make encrypted backups which you can save wherever.
I like Authenticator Plus but I really wish it had a search feature. I have so many damn accounts in there and lots of them don’t have their own icons.
I fell in love with 1Password (and immediately switched from LastPass) once I discovered it can parse and save the Authenticator qr code and auto-paste it at every 2FA step.
Yes and no. There's two advantages to TOTP 2FA: The "second factor", and the "one-time password".
The one-time password advantage still exists if you use a password manager, and I'd argue it's the main advantage. It greatly increases the effort required to successfully hijack a login flow. It prevents account takeover via password reuse / leak. It does not help if the OTP seed leaks as well but it's still a lot more secure.
Now on second factors: What is it? If a password is something you know, a second factor is something you either have or are.
The wikipedia page on MFA (https://en.wikipedia.org/wiki/Multi-factor_authentication) gives a good summary of the philosophy behind it but concretely, the separation between a phone's encrypted 2FA database and your local password manager's encrypted database is not that large. They will likely be on the same network (the 2FA device is unlikely to be airgapped); they will likely have the same owner; etc.
Unless your threat model is "people are already on my machine and have access to my RAM, or my files AND system-level keystrokes" (in which case I'd argue you're already beyond fucked), then a password manager won't be any less of a second factor than a phone authenticator. Either will be less secure than a hardware key.
Risk does greatly increase if you're using a browser extension as the threat level becomes the browser's sandbox. But security is also about convenience, otherwise you'll find people sharing a taped hardware token with its pin written on a post-it note next to it and call it compliant.
You are a user of hot new site clown-mishaps.example and Jim is a Bad Guy of some sort.
1. Credential stuffing. Jim has 10M username / email address / password combos from some "Hacker" site and he is trying all of them on clown-mishaps.example because he just figured out their rate-limiting depends on session cookies (Oops)
If you have TOTP then this doesn't work, but, if you have a password manager you should also be using unique passwords, that is after all what the password manager is for, so, you should be immune to credential stuffing anyway. This seems like a wash.
2. Live Leak. Jim discovered that the credentials backend for clown-mishaps.example uses say a noSQL system in the cloud on a non-standard port, he connects to this system and queries your credentials to log in as you.
TOTP makes no difference here, no matter how you do it, the seed stored by clown-mishaps.example is enough for Jim to make TOTP codes. If they used a password hash and if your password manager makes decently strong passwords Jim can't figure out your password but TOTP didn't help.
3. Slow Leak. Jim found the S3 bucket "clown mishaps pwd backups July 2020" with a text SQL dump of a historical database. Oops.
TOTP still makes no difference here unless you didn't enable it until after July 2020, but then that's the same if you changed your password, or only created the account later.
4. Phishing site. Unfortunately clowns-mishap.example is a phishing site. It looks just like the real thing. Jim sets it up to capture live logins, cookies and so on. You can get tools to help do this for popular login systems.
If your password manager is hooked up to tell you about phishing attempts you might get some warning, but TOTP makes no difference to that. Whether not knowing your TOTP seed hurts Jim will depend on the details of the site's security systems, but in most cases if his phishing site fools you into attempting to log in it's game over.
WebAuthn completely protects you in all four scenarios, and a password manager does at least potentially help you in all four scenarios, but TOTP isn't really adding anything on top of the password manager except in scenario #4
I use it in this way too, but I had been wondering about that as well.
Taking a stab at reasoning through this:
My understanding is that having a second device means that if the password was stolen, someone still needs another secret to log in successfully. In this case, if a password was stolen from the site itself, the 2fa code generator is not.
However, if the 1pass master key was stolen, then both the password and any 2fa code gets stolen as well. That puts the main vulnerability on the master key one uses for 1pass. (So looking at it that way, one should never use the master key as a password for anything else).
It does lose the advantage of having a second authentication device, though maybe not necessarily losing the protection of a second factor.
Is there something I overlooked in this? I’m no security engineer so I am not used to thinking in this way, other than maybe when I play Go.
> My understanding is that having a second device means that if the password was stolen, someone still needs another secret to log in successfully.
Stolen from where ?
The vast majority of attacks which impact real people on today's web involve the data being stolen from servers in bulk.
You should assume bad guys will steal all the available credentials. Is it possible they're too dumb to also dump the table labelled "TOTP Seeds" when they get the "Hashed passwords" table from your favourite web site? Yes, but you can't rely on attackers being incredibly dumb even though many of them are.
A password manager makes TOTP moot for these scenarios as I outlined in a separate message in this thread. TOTP doesn't hurt, but if you have to pick between spending ten minutes today adding TOTP codes to accounts in your password manager or going through changing the password from "Liverpool2005" to an actual randomly generated password on a few sites you imported but didn't give fresh passwords, the latter will make much more practical difference.
Yes, in a way. But I find it so incredibly convenient it's actually encouraging me to enable 2FA on all websites that support it (and 1Password lets you know if the website does).
Yeah the QR code is not the special part. IT's the UX: 1 click and 1Password reads the QR code and adds a live authenticator code alongside your saved password, and auto-copies it to clipboard on mobile (and auto-pastes it in the 2FA field on desktop). So its like having a password manager and 2FA authenticator app rolled in one. I know it's sorta missing the point, but it's encouraging me to enable 2FA everywhere, as the hassle is now gone. (and most important sites detect when a sign on is unusual anyways).
No problem! When you go on a website that supports 2FA, it usually shows you a QR code to scan in order to setup a 2FA token. Just open 1Password to your current login and click on the tiny little QR code button. 1P detects it and adds it to that login. Blew my mind as well.
I wish more sites would integrate a two factor option into their apps instead of requiring a second app - for example I should be able to two factor Amazon via the Amazon app instead of having to use a second app for the one time key generation.
Microsoft and Salesforce have made it pretty slick but it’s still two more apps I have to keep that I don’t really want.
Transferwise nailed this. 2FA request pops up as a notification, touch or Face ID approves it. It’s the canonical example I use when poking other apps to provide a similar UX.
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.
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.
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)
Having your 2FA tokens on something where the keys available to the user changes it to something you know.
An encrypted file with that an application decrypts is still available to the user. ie, they keys are loaded into memory. In most phone and hardware tokens the key is done by a dedicated security chip and is never loaded into main memory.
So? The code is what matters, not the key. Keeping the key on a dedicated chip doesn't matter if the adversary wants the code and has the capability of reading your process memory.
"One thing you have, one thing you know" is a nice heuristic but it isn't an actual threat model analysis.
This seem to negate the whole purpose of 2FA - now your second factor becomes "something you know" instead of "something you have".
What I really want (and would consider a "missing authenticator app") is an app that stays on the phone and keeps all keys there with a client companion app for desktop that communicates with the mobile via Bluetooth to automatically fill the 2FA codes.