I have Thirty-One 2FA codes
2fa passwords security usability · 7 comments · 650 words · read ~1,044 times.
Last week I wrote about how I had 800 passwords in my password manager. It was intended to highlight the ridiculous proliferation of online services, and how redecentralising identity comes with a manageability problem.
I now want to talk about 2FA - Two-Factor Authentication - the random codes you have to type in every time you log in somewhere secure.
This week, I've moved all my 2FA tokens from Authy, to the open source andOTP app. It was mostly painless exporting the Authy keys - but took a while to manually check each one. Do I really need this many 2FA tokens?
It's good that my webhost uses 2FA - but annoying that they have two separate ones for my account and my control panel.
I've got a bunch of Gmail accounts - it is frustrating scrolling through remembering which G-icon goes with which G-service.
There's a few different Microsoft ones because I'm not sure of the collateral damage if I try to link my Xbox, Skype, and Outlook accounts.
And the usual smattering of hardly-used services which offered 2FA, so I set it up.
Oh, and a few services which don't use standard TOTP - and insist on using their own app or hardware token.
Is This Secure?
I don't know any more.
In security, we usually talk about the benefits of having your security split between something you know (a password) and something you have (a token). But I've effectively combined them. My phone stores passwords and tokens. If someone steals it and can break through my biometrics & PINs - they've got the keys to my kingdom.
If a crappy service has leaked a passwords, which I've reused elsewhere, then this 2FA set-up provides extra security. But fewer than 5% of my online accounts support 2FA - so that's a minor benefit.
The Alternative?
I tried using a YubiKey - and I just couldn't get on with it. The software was too flaky, hardly any services support it, and my keyring is rarely to hand.
So I'd have to keep an easy-to-lose physical token - as well as a phone for every service which doesn't support it.
Text For Details
As well as the codes in my app, I have a bunch of services which will only use insecure SMS for 2FA:
Quite why these services are stuck in the dark-ages is beyond me. Possibly they just want my phone number for marketing purposes?
What's Next?
The username / password / token pattern is becoming increasingly unsustainable for me. Having a multitude of security apps is marginally more convenient than carrying around a big bunch of keys. But it is frustrating find the right app, searching through for the right icon, typing things in before the timer expires, and proving my identity multiple times daily.
I could turn off 2FA and re-use the same username/password everywhere. That would be a hell of a lot easier for me. But I don't want to reduce my security that much!
I could sign in to everything using Facebook. But even if that weren't ethically dubious, not every service supports that.
Both Google and Authy have a useful service whereby they send a push notification to your phone and ask you to confirm your login. Cool, and easy to use. But, again, limited support and the same risk of my phone being the single point of failure.
What's the alternative? If you know - please leave me a message in the comments.
Google's Abandoned Android Authenticator App
Andrew McGlashan says:
SMS 2FA should be outlawed and it annoys me when the media talk about 2FA as if SMS is the ONLY method when they should be saying that TOTP is the method of choice and make it clear that any system that uses SMS is considerably less good (due to how insecure the mobile phone network actually is).
I never have had problems with too many passwords in KeePass (I now use mostly KeePassXC), I have way more than 800 entries.
For TOTP, I use my own Python script to generate the codes (which are not random btw, but based on the time of the server and a secret code). The "application passwords" that Google uses are less secure than many of my passwords because they become a single factor of a reduced character set (lowercase a through z only) and reduced and fixed length.
I create QR codes using qrencode on a Linux CLI, KeePass 2.x has a nice add-on for QR codes. I think that built-in support for QR codes will be part of KeePassXC 2.4 when it is released; it has been talked about.
Many people also do not understand that TOTP doesn't require the use of Google Authenticator (I'm glad you are at least using an Open source app and moved away from Authy) and it isn't the "domain" of Google.... it's much like Apple not inventing things, but implementing them and carrying on as if they invented them fully themselves.
Also, I have less trust than most with Android or other mobile devices so anything that needs a login but can wait for a "real" computer.... can, well... wait.
All the tracking of Android by Google themselves is bad enough, but apps have all sorts of other tracking and I would rather avoid those apps; I didn't need them yesterday, why do I need them today?
1password now has a 2fa module. It would essentially scan the QR code provided by the services, and on top of storing the username/password pair for your logins, it can also store the relevant 2fa information, generating the codes for that.
Which makes it the same as “if someone got your phone and broke through your biometrics”, except instead of using 1p and a set of TOTP apps, you use one app.
That said there are problems with the QR codes themselves, see https://medium.com/crypto-punks/why-you-shouldnt-scan-two-factor-authentication-qr-codes-e2a44876a524.
A potentially viable alternative is using a passwordless login instead – you want to log in, give the service your email address, and they mail you a one-use token that’s good for half an hour. The downside to that is if your email service is offline, you can’t log in.
I’m also about to move away from Authy, as much as I can, due to them needing my phone number for accounts, and as we’ve seen with Facebook recently, phone numbers are used to connect accounts between services and advertising.
It would be interesting to set up accounts using your public key and whenever you need to log in, you’d present your private key, much like ssh connections.
G. McDorman says:
LinkedIn now supports authentication apps; they only mention the Microsoft authenticator but andOTP works just fine.
Note that with AndOTP, there's an extra layer an attacker has to get through, if you've set it that way: the andOTP password. You can use a strong passphrase here, hopefully one that can't be guessed if the attacker has discovered your password manager's master password.
MayeulC says:
Well, bitwarden can do 2FA with TOTP as well 🙂
I also recently moved from AndOTP to Aegis, which tries to maintain higher security standards.
Ideally we'd use client certs everywhere, stored in a security element. I think webauthn gets close to this.
52 and counting...
52!
If your OTP generator makes it hard to distinguish between different Google accounts, it might be time for a different OTP generator! There's plenty of them out there; consider having an explore.
You mentioned the fact that you've effectively "combined" your two factors by using your phone (secured with e.g. your biometrics) as both your password safe and your OTP generator. You're right! But this doesn't completely undermine the value of that second factor: I wrote about this recently, but the essence of it is that part of the value of OTP is that the authentication code changes relatively rapidly, which helps to mitigate replay attacks. If your username, password, and OTP are stolen (keylogger, intercepting proxy, phishing, shoulder surfing, etc.) at least they can't be re-used a few minutes afterwards. It's not much, but it's better than nothing.