Everyone in security will tell you need two-factor authentication (2FA), and we agree. End of article? Nope. The devil, as always with security, is in the details. Case in point: in the last few weeks, none less than Google messed up with their Google Authenticator app. The security community screamed out loud, and while it’s not over yet, it looks like Google is on the way to fixing the issue.
Since 2FA has become a part of all of our lives – or at least it should – let’s take a quick dip into how it works, the many challenges of implementing 2FA correctly, what happened with Google Authenticator, and what options you’ve got to keep yourself safe online.
You probably know or use Google Authenticator, Microsoft Authenticator, or an app like Authy. What all of these authenticator apps have in common is the generation of a time-dependent six digit number, given a secret key. Perhaps you scanned that secret key into your phone in the form of a QR code? If any of the above sounds familiar, you’ve used a time-based one-time password (TOTP).
Under the Hood
What goes on under the hood with TOTP is nothing secret, and in fact you can do it yourself in just a few lines of Python if you’d like to. Basically, it’s taking the secret key, hashing it with a timestamp, and pulling six digits out of the result. The server to which you’re authenticating also has the secret key and a clock, does the same computation, and if they match, it knows that you are you!
This is a great system because a new six-digit “password” is regenerated every 30 seconds or so, which makes it impossible to guess before it expires. Using a one-way hash of the secret and the time ensures that even if an attacker is listening in, they can’t generate the next key, or figure out your secret key from the intercepts. And even if you get phished into typing your six-digit TOTP into a bad web site, it’s a one-time password, so the damage is limited to that one login. (Of course, if they can wipe out your bank account in that one login…)
The underlying secret key in the TOTP is longer and more random than any password a human would choose, and if you’re like most people you haven’t ever even seen it – it’s in that QR code you scanned. So the TOTP secret key is a good password, and it’s only stored in two places: your phone and the server to which you’re authenticating. And therein lies the rub. What happens when you lose your cell phone?
Backing Up
Most authenticator apps have a method of backing up the secret key to another device. The most common is to generate a QR code with your secret key so that you can just take a picture of phone one with phone two. That way, only someone looking over your shoulder at that exact moment can steal the key. But what if you want to back the secret up to the cloud? That’s where Google Authenticator got into trouble.
The secret key is a secret, and in the case of a 2FA token, it’s probably a secret that you really care about. What do you normally do when you send or store secrets? You encrypt them, right? Guess what Google didn’t do when sending the secret key between your phone and their server!
How should cloud backup be done right? It should be end-to-end encrypted. That is to say, on phone one, you should have to type in yet another password to encrypt it before it’s sent out to Google. On the receiving phone two, you enter that same password again to decrypt the TOTP secret. In the middle, Google or anyone else listening in would have to break your encryption to steal the TOTP secret, and you have the convenience of the cloud.
What could go wrong with Authenticator sending the keys in plain text? For one, you might not want to trust Google with your TOTP secret keys. Of course, if you’re using Google Authenticator only to log into Google, they have the secret key already. But if you’re storing all your TOTP keys in one basket in one convenient app, then Google (or anyone who hacks Google) has access to your bank account too. If Authenticator let you encrypt the keys before backing them up, you wouldn’t have to trust Google at all. Or mostly not.
Trusting TOTP
Authenticator apps are a strange bargain. On the one hand, they provide a non-repeating login that will help defeat eavesdroppers. On the other hand, the secret needs to be used in an unhashed form, both on your phone and on the server that authenticates it. This means that there’s not a super-safe way to store them on the server side, unlike regular passwords which can be stored salted and hashed. So the safety of your TOTP keys relies on the authentication server not getting hacked. Your TOTP keys are much more vulnerable to a server database breach than a regular password.
The TOTP key is also stored in some kind of readable form on your phone. Maybe it’s encrypted with another secret key, but if someone smart got you phone, you’re probably cooked. Worse, this means that you have to trust the TOTP app. Unsurprisingly, there are numerous cases of malware authentication apps out there that simply steal your TOTP secret.
But you also have to trust the authenticator app to respect your privacy. While in principle a TOTP can be generated without any Internet access, and indeed that’s what hardware tokens like the Yubikey do, most cellphone-based authenticator apps phone home. Particularly egregious among these, Microsoft Authenticator sends personally identifiable data about you back to Microsoft even before you’ve accepted the terms and conditions, and does so afterwards when you use it. Authy may be even worse, transmitting which websites you’re logging into. (Video link, great explainer.) It’s not clear whether the info that Google Authenticator sends home identifies you uniquely, but it’s definitely more than is necessary for the software to function, which is none.
Open Source
This all sounds pretty bleak for 2FA. On the one hand, backup can be difficult, or hard to get right. On the other, the companies that provide you the software are spying on you. Should you just give up?
Nope! Remember, the TOTP system is open and even simple to implement, and there are many open-source apps out there that don’t invade your privacy. RedHat’s FreeOTP runs on iOS and Android, and would be our first choice if we didn’t roll our own. Aegis Authenticator also comes well recommended, but only runs on Android. There must be others, so if you have a favorite, chime in!
Real security come from a TOTP+PIN for authentication.
Real security comes from keeping things to yourself, once if’s outside of your brain it’s vulnerable.
That only works if you never take the tinfoil hat off. The moment you do they’ve got you
You made me pit my coffee, haha.
Not tinfoil hat, if two people know one thing it’s no longer secret.
5G vaccines exfiltrate teh data too.
Rumor has it that the Tinfoil hats work…but you can only get aluminum foil now a days…and aluminum foil hats won’t protect you
That’s exactly why I use 2 layers of aluminum in my hats.
See, the problem is that you need to pick a different metal as a second layer. As long as they can’t guess what type, you’re safe.
There are man-in-the-middle attacks against TOTP, where the attacker fools you into entering your six-digit number into a form that they control, and then uses it (quickly!) to impersonate you.
They have to have your password from somewhere else, but this has been making the spearphishing rounds lately.
You can defend against this by automatically checking the website address you’re communicating with, which is what U2F / FIDO2 do, for instance.
TOTP is better than just a password, but it’s not the end game either.
Social hacking is still a very effective way to get passwords. Another way is to hack someone’s PC and show them different pixels on their screen (they can change recipient and amount).
A hardware authenticator, used by some banks, can show you the amount and the recipient, which can help reduce this problem. They often require a separate authentication for login and for (large) transactions.
KeePassDX
The phone app based 2FA is a big no no for anything and everything moderately serious for obvious reason.
A dedicated MCU-based device with camera to read QR code reader for reading request and with display to show a QR for reply is the one and only viable way to obtain somewhat secure 2FA. Howgh!
Word.
My bank has this for online banking. They display a QR code that includes details of the transaction, and I use a dedicated device with a camera that also reads a secret from my banking card’s smart chip, mixes them all together, and presto.
(No idea if encryption / hashing is symmetric or public-key in this thing. It could be as simple as HMACing the data in the QR… anyone know how the Sparkasse does it?)
Of course, you have to log into the bank account first with an account name and a (horrible!) 5-character PIN as well, so it’s a real 2nd factor.
I’m inclined to think that conventional hotp/totp devices that generate codes and don’t have inputs or other functions are as secure as anything reasonable when it comes specifically to proving the second factor. Maybe that’s because I don’t know what specifically you’re saying the QR code would do for that part. If it’s like what Elliot described, I can agree that when you want to conduct a transaction, monetary or otherwise, a device that (ideally) displays the details of the transaction and can only approve that exact transaction rather than a general approval sounds like a step up in security. However, just like in that example, the final device is a simple bank card whose only purpose is to prove itself when prompted. That is a loosely similar sort of second factor as the conventional hardware (but not software) hotp/totp tokens provide, or the yubikey/u2f/fido/etc stuff. It wouldn’t be as secure if the transaction device could be exploited to gain the secret when it wasn’t intended.
The 2FA that is foisted on us is a disaster. Now I am required to entrust my bank account to the customer service department of the phone company or some email provider. WTF!!?
Well if you gave them your account number for bill paying purposes which is kind of a big no no regardless of security. Credit card would be much better.
Not worried about the phone company — identify theft followed by sim card hijacking is the problem.
Or MITM with a spoof basestation.
Verizon offers a $10/Month/Line discount if you give them access to your bank account. Doesn’t do this if you have automatic bill payments sent to them from your account, or give them your credit card number.
We always pay from the bank, and never give companies access to are accounts. We also do not use our phone to pay. Google is the last company I want to have my credit card info. They probably already do even though I’ve never given it to them directly.
TOTP as 2FA is better than SMS or e-mail. Auth apps aren’t perfect, but they’re not horrible either.
Auth apps are fine, if you always carry a smartphone and have good security practices using it. I submit that the average smartphone user *doesn’t* practice good security.
As for banking, my bank tends to only demand 2FA for “suspicious” transactions. Unfortunately, a “suspicious” transaction also looks EXACTLY like an “emergency” transaction. Let’s say I’m in a foreign country and get robbed/need medical care/need a flight out of there/lose or drop my phone…. the bank would see a big purchase or cash withdrawal, that is unlike my other recent purchases and occurs in a strange place at a strange time.
My bank also discontinued issuing OTP tokens in favour of just sending an SMS for authorisation. So if I’m overseas and my phone dies (or I chose not to pay extortionate international roaming charges on that trip) then I am screwed.
TL;DR. Banks suck and “security theatre” is alive and well.
Replying to myself here, now I see Elliot’s comment down-thread that says “using a cell phone for anything security related is asking for trouble, because cell phones are full of malware and get lost all the time”
I think we’re in agreement on this :-)
“The server to which you’re authenticating also has the secret key and a clock, does the same computation, and if they match, it knows that you are you!”
Even syncing apps run into the dissimilar clocks problem.
as long as the 30 seconds window is close enough it works.
And setting a clock on any (relevant) device to be +/-5s to UTC should be no problem.
And don’t tell anyone, but many services will accept a few keys plus or minus in the time sequence. So there can be a few minutes slop sometimes.
And for supporting hardware devices with drift, sometimes there’s support for resyncing; I think I saw one where once resyncing is approved you enter codes until it figures out when you drifted to, and others where when you enter a valid code it updates your offset so that the time you entered it is the new “now”. It’s also been a thing with HOTP especially for car keys since you can get out of sync very easily.
Funny enough, I had to enter my TOTP for a Google login today twice before it worked.
Must be my computer’s clock is out of sync enough to mess this up? Time to run NTP.
For Android I highly recommend AndOTP which is opensource and much better for searching and use than anything else I’ve used. It also encrypts your OTP with a password. I always backup my OTP secrets in my Keepass database (and I recommend you do too), but obviously you need to make sure that this is well-guarded and backed up.
In case you don’t already know, Keepassxc (and Keepass2Android) support TOTP directly, so you probably don’t need AndOTP.
AndOTP is, AFAIK, unmaintained for a few years now. https://github.com/andOTP/andOTP
That doesn’t mean there are any problems with it, but that’s why I didn’t recommend it.
This article is misleading, 2FA is not only TOTP. If you can access you bank account with just a TOTP, you’re back to “1FA”. With 2 factor authentication, you usually start by entering a secret (password, pin), and then you’re asked for either a TOTP or a “device” based code (pin by sms or email, confirmation from an authentication app, scanning your access card, etc). In all cases, you need two different authentication methods, to mitigate the vulnerabilities of the other.
Agree – misleading. 2FA is requiring two distinctly separate methods of identification.
I am unsure as to whether logging into your bank account on your phone, and then receiving your TOTP on that same phone would actually count as 2FA? Does it? If not, it is 1FA…
I’d call it 1.5FA. Why? I is a separate method of authentication, but on the same device. In my book, if the authentication of a device is on the same one, -0.5 points. Of course, the scale is exponential, so 1.5 FA is still much worse than 2FA. ( two separate devices, separate authentication)
TOTP as a second factor has always bugged me fundamentally. Back in the old days there was this “something you have”/”something you know”/”something you are” concept behind 2FA.
TOTP is _not_ something you have, it’s just another something you know. I rant on about this for quite a while in the article of mine that I linked, and it’s actually the reason that I worked through the Python code to demonstrate that TOTP is just a hashed password.
IMO, using a cell phone for anything security related is asking for trouble, because cell phones are full of malware and get lost all the time. But they’re so darn convenient, and TOTP is better than using the name of your high school, which is what people would be doing otherwise.
But I’ll take umbrage with y’all calling the article misleading. It’s the whole darn industry that’s misleading you on this one. I just didn’t have room to fight that fight in this article.
>TOTP is _not_ something you have, it’s just another something you know.
This times ten! The only exception is if you are confident enough in the hardware totp/hotp token AND the security of the secret on the server side that you’re willing to pretend it’s something you have instead of something you know. Which is not always unreasonable; we’re used to pretending a physical key is something you have instead of a secret you know (the depth of each cut in the key).
Everything is “something you know”. If I know the shape of your key, I have it. If I know your fingerprint or retina pattern, I have it.
TOPT works because (provided the Authenticator app is secure) the key stays in the app, and you gain some protection against phishing, MITM or password reset to compromised email attacks.
Apart from quantum stuff and theories about information and existence, which may say whether anyone could know enough about a device in order to simulate having it, at the moment eyes and fingers are still something we have. Right now, a person can verify that a thumb is attached to an owner and so is its eyeball, and we could make a computer do the same if we truly needed to – e.g. prick the finger, and make the owner of the eyeball read something through it while being scanned. A person can’t verify if the key someone’s holding was made legitimately or not, and especially not whether the password is theirs. If you build a device that can’t be duplicated, e.g. because trying to access the secret would destroy it, then if someone has the output they reasonably must have the device. But TOTP codes in an app can be very easily duplicated – it’s a feature.
@ Dan, and re: “Everything is “something you know”.”
I’ll disagree. The way Yubikey and other similar hardware tokens are made, and FIDO2 implemented, there’s essentially no way to get the secret out of the hardware. Public key crypto for the win.
With a high res photo “something you are” can be “something you know”, as you say. But biometric readers are getting more sophisticated as well, so nowadays you have to have the imaging across multiple spectra. That’s a super fun game of cat and mouse over the last decade, though, and I’m not up to speed on who’s winning right now.
But re: door keys. Totally. And so little entropy too. Did I ever tell you about the time I got into the wrong Toyota Camry because the key worked in some random stranger’s car that happened to be the same color and parked in the same lot as me?
Re: keys opening the wrong lock, there’s even a few keys that are so well known to be reused that in various places which sell lockpicks and shims and the like, you can buy small bundles of about 5 keys that will open large fractions of all the things in that category – e.g. most of the cabinets in offices, many fleet vehicles, many utility boxes, etc.
Couldn’t a bit of public-key cryptography fix this issue?
Server: shared secret & public key.
You (phone/whatever): shared secret & private key.
Login process:
1) TOTP is generated and signed with the private key.
2) Server verifies signature against public key and only then accepts correct TOTP.
-> Even if shared secret is stolen from server attacker still can’t generate working TOTP.
Of course the private key would need to be encrypted locally with a password…
TOTP was never the best 2FA system, but it is the most convenient, and when most people don’t wan’t to use even TOTP, make them use better solutions like this one would be harder.
that’s because it isn’t a 2FA system. It’s a 1FA system…
You have to login on the phone, that’s the second.
See U2F / Fido2. https://en.wikipedia.org/wiki/Universal_2nd_Factor And yeah. This is the best idea out there, AFAIK.
Public-key crypto fixes everything! :) (Except the key trust problem.)
I’ve often argued that TOTP is just a password you don’t have to transmit every time, but which nobody bothers to protect as well as they do normal passwords. I saw someone include a screenshot of their QR code in order to make a guide showing people how to sign up for MFA… Nothing actually tells you not to do that if you don’t know how it works, and even if you know it’s been leaked sometimes you can’t even reset your own TOTP secret.
That being said, not having to transmit the password every time is great if you’ve got a device to track the time and do the TOTP calculation for you. So is having only a short sequence of numbers to type instead of something elaborate.
I ‘love’ (sic) these 2FA systems!
I don’t have a mobile phone, but every time I encounter a system that wants to send me some sort of code it insists I enter a mobile number. Why is there never a ‘ … but I don’t have a mobile’ solution?
I was set-up on MS Teams a few years ago using a 2FA system using somebody else’s mobile number. Now, every time I start MS Teams it wants to send the code to the number they have recorded for me. But it’s not me, it’s somebody else, so I never see the number! That person left the organisation, his mobile was reset and issued to somebody else, and the SIM was cancelled. So, the number recorded for me won’t work anyway!
So, I don’t use MS Teams any more … as a result my productivity has increased!
Your move, 2FA afficianados.
Graham, I don’t know who you are, but you appear to be a gentleman and a scholar. I admire your commitment to living life in the modern world without a mobile phone, let alone a smartphone. You’ve got the moxie that I fancy myself possessing but don’t really.
I also love the remark about your productivity increasing after you ditched MS Teams. Sounds like the *actual* problem got solved.
Good man, Graham. I hear you on the “higher productivity.” People think you’re bonkers when you say “I don’t have a phone” but then they tend to go quiet and let you get on with your work :-)
Ugh. I tried setting up my VPN to use Google’s 2FA. It was terrible! It was so inconvenient to use when it worked. But about 2/3 of the time I just plain couldn’t log in!
Really long passwords plus KeePass… I like this so much better. And no trusting any third party is required!
Well either way i wanna have a long and unique password so… But i never dared to start using KeePass in private, for work it was perfect but there i only had one computer!
I worry that I’ll grow sick of not having the latest database on the current device, and then just place it in a cloud.
But if i do then i might just as well use a cloud password manager?
I see people talking about keeping their TOTP secrets in KeePass, and I also see that BitWarden has a place for them too… but I thought the whole point of MFA was to not put all your eggs in one basket? If you put your TOTP secret and your password for a given site in one place and secure them in the same way, it’s not really a second factor anymore, just a second step.
I always understood MFA to be at least two out of “something you have + something you know + something you are”. It’s fine to use two different “something you have” or “something you know”, etc, but if they’re colocated they’re essentially one single factor.
Great article highlighting the importance of two-factor authentication (2FA) and the challenges associated with its implementation. The recent issues with Google Authenticator serve as a reminder that even widely-used apps can have vulnerabilities. Backing up the secret key securely is crucial, and it’s concerning that Google Authenticator didn’t encrypt the key during cloud backup.
Trusting the TOTP system requires relying on the security of the authentication server and the authenticator app. Storing TOTP keys on servers poses a higher risk of database breaches compared to salted and hashed passwords. Additionally, if someone gains access to your phone, the TOTP key could be compromised. It’s crucial to choose authenticator apps that prioritize privacy and don’t transmit unnecessary user data.
Fortunately, there are open-source alternatives available that offer privacy-focused solutions. Apps like RedHat’s FreeOTP and Aegis Authenticator are recommended options that prioritize user privacy. It’s important to be proactive and choose secure and trustworthy apps to ensure the safety of your 2FA implementation.
The more i hear about backing ut the secret key, the more false it rings.
Would it not make more sense to back up a Different secret key??
That way, you have an alternative if your key is compromised.
There needs to be more mechanics behind this, bit still.
Just give everyone a secret 3rd secret key, that they don’t even know about.
It can be their ID# (e.g. password = ‘USA:” + SSN.tostring().
Problem solved.
When it comes to trusting a third party, I’m a fan of authentication protocols like VivoKey, which relies on multiple AES keys unique to me, but I completely understand that most people wouldn’t be comfortable using it because those keys are uniquely accessible to me because they’re stored in a subdermal implant that has to be read via NFC – implantable technology is a niche biohacking subculture thing that that would most likely only go mainstream/mass market in a a dystopian sci-fi future.
Cool! But for thyless motivated, they could just use a key card instead?
That’s not how TOTP or U2F are designed, but I agree there should be a recovery key or root key which can create a new private key with precedence over the old one.