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.
- 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.
Does anyone know of a suitable alternative?
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.
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.
I was desperate for an app like this a couple years ago, but 1Password wound up adding mfa. Regardless, I wish the creators luck, this looks very good! A real “mac-assed app” https://daringfireball.net/linked/2020/03/20/mac-assed-mac-a...
Edit: OTP Auth has a macOS version, too. Separate purchase.
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
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.
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.
Aegis does backups, biometrics and is open source.
I also don’t know what encrypted while in iCloud means. Is it your key, my key or Apple’s key? Is the key also backed up to iCloud?
It’s important as 2FA is the most critical thing we need to get right next to whatever mechanism secures passwords.
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.
Having an extra option is nice though. But it’s often one or the other.
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.
(I'm aware of the implications, don't need a lecture)
> All data is encrypted even if is stored in iCloud, so you never have to worry about nasty hackers.
That looks like there's a word missing or something.
Edit: Choice is great! Keep up the fantastic work.
I found the user interface to be clean, a big plus in my book.
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.
"One thing you have, one thing you know" is a nice heuristic but it isn't an actual threat model analysis.