TOTP for 2FA is incredibly easy to implement. So what's your excuse?
drewdevault.com
drewdevault.com
TOTP is almost purpose made to be phished. There are just six digits, most people are getting them from a separate device, and you can type them into the box on phishing-site.example just as easily as real-site.example, there's no indication this might not be a good idea, and hey, phishing-site.example can even give you a "Thumbs up" indication that you got the digits right, hooray.
All the bad guys need is one of dozens of ready-made tools to eat the input on phishing-site.example and feed it into real-site.example, stall the duped user and give them access. So this is something you "don't have to worry" about only in the same sense as duplicating mag stripe cards, or somebody cutting off your bike lock, or a dozen other things we know crooks do all the time with low effort and little risk of being caught.
Well, that's a tad hyperbolic. While TOTP codes have no protection against phishing, an attacker still requires interaction from the account owner every time they want to make use of it and can't use the compromised account without the owner being able to notice it. Granted, someone getting phished might not notice. Still better than nothing (but not better than a password manager checking which site it's filling the login into)
Also the TOTP seeds are not stored in secure enclaves on phones but rather in plain text. Secure enclaves on phones do not have native TOTP support. Any application sandbox vulnerability on the TOTP seed containing device can give an attacker the ability to generate unlimited codes. Google Authenticator stores the secrets in an SQLite file.
It gets even worse when you consider TOTP secrets must /also/ be stored in plain text server side, normally sitting in a SQL database to be silently dumped through a pile of backend vulnerabilities most companies do not patch allowing bulk 2FA bypass.
TOTP is a fundamentally broken design that is negligent for any organization to support at this point alongside SMS. Everyone has one or more WebAuthn capable devices now regardless of if they realize it or not.
Today the right call for 2FA is to implement WebAuthn with the verification happening in a Confidential VM, HSM, Nitro Enclave or similar. Support only this.
Then, they asked me to verify a code and send the 5 digit code to them. Sure, ok (lol). I receive a code from google voice. Then they got really angry because I sent them 69420. I then tried to send them some tubgirl (nsfw) pictures, but apparently they don't see those.
About 20 minutes later, I got yet another "person" doing the same exact thing, but by then, I was bored and just blocked them.
I'm honestly not sure what the code was for. My guess is that my FB uid is associated with my email address in some database somewhere, so let's assume they have my email. The phone number I originally texted them from is not connected with anything 2FA. I almost never have 2FA associated with SMS, since that is just dumb and when I do, it is with another number that I don't use as my main phone number.
So, maybe they have some account of mine somewhere that can be validated with a 2FA sms. If they have my email, they can request the code for that account, plug in my email address + code and somehow get into my account. I don't know. It was odd... I kind of wish I had some sort of honeypot account I could have used to see what got 'hacked' after giving them the real code.
Also had a firewall rule that dropped NTP packets and took 3 months for the click to drift before anyone with 2fa codes couldn't log in anymore.
Can you even address this without defeating the purpose of 2FA?
You could also try human-in-the-loop authentication by having the user describe their account contents to customer support. However, that's notorious for allowing account takeovers because people are always the weak point in security.
It’s frustrating to see technical people discount or ignore that side of the deployment work, because that’s the kind of issue that actually blocks most security and cryptography measures in practice.
If I had a thousand dollars for every time I heard “just make the user keep a key safe” I could fund so much UX research :)
* generate, authenticate, distribute, back up
https://github.com/andOTP/andOTP
(And yep, I found out about Google Authenticator the hard way, trying to transfer from my previous phone!)
You're exactly right! The pure TOTP algorithm is the easy part. The underestimated part is the extra overhead of human customer support of users that messed up 2FA TOTP.
Title of blog post asks: >So what's your excuse?
One excuse is the issue outside of 2FA algorithm: lost 2FA credentials has more complicated recovery than 1FA. Many websites don't have an established procedure to deal with 2FA customer support.
Whether the 2fA user uses a smartphone, or Yubikey hardware, or software like WinAuth, it's not the simple process like 1FA of "just let customers self-service their own password reset by emailing a temp password to the email address we have in our records".
Case in point is me. Back in 2020, my web hosting service forced everyone (admins) to 2-factor TOTP and I kept putting it off because I was fine with just using a simple 1-factor password to manage my accounts. But then the day of reckoning came for 2-factor and it happened on a day where I was juggling a lot of problems and was in a hurry to login to my admin control panel to fix a configuration issue.
I didn't want to use my phone number for 2-factor because I didn't want the hoster to have it (prevent spam) so I downloaded "WinAuth.exe" and did whatever extra steps I needed to log in. But because I was in a hurry and didn't take meticulous notes and screenshots of what I did to enable 2FA, I now have no idea how to log back into my email host admin panel with a "verification code". I guess they gave me a "secret" for WinAuth to generate TOTP but I don't remember if I copy-pasted it somewhere or saved it to a file I can't find.
Either way, I'm now a customer support ticket because I'm locked out of my account. I was logging in successfully for 15 years with 1-factor before 2-factor came along and complicated the password situation.
Yes, it was my fault that I lost my TOTP procedures but that's not the point. The issue is that 2FA helps improve security but it also adds underestimated extra customer support issues and small websites can't deal with this extra workload. Just copying some trivial algorithm for TOTP doesn't solve that.
You should record the last successful count/time window to prevent code re-use. In the rare case that you expect clients to use devices to generate the codes that may be offline for a long time (or never connected dongles) you also need to compensate for personalized time drift for each device.
Solution: Backup/recovery tokens (never require phone/OOB recovery by default). Use email as a fallback 2FA if the service isn't critical.
For internal services/services at a business org, put in workflows for getting manager voice auth/phone call/etc. for more secure and trusted recovery validation.
Anyway, the point is for simple TOTP, it's a lot of security improvement for relatively minimal, one time work.
Certainly it is, and where sites have it available I prefer to use it over those stupid SMS codes. But -- having worked closely with marketing/UX teams in the past, I'm fairly certain the hurdle isn't technical, it's that most users can at least sorta understand 2FA in the form of an SMS message, not so much using a dedicated password manager app that keeps track of TOTPs. I like to think this explains why lots of "big" sites that deal with customers from all walks of life (like banks and utilities) offer, at best, SMS 2FA.
Maybe for the IT group. Not for the end-user.
SMS MFA on Apple is so easy it's ridiculous. The OS autofills the MFA form with the received value. There's nothing for the user to do beyond flipping a switch in settings to allow SMS messages to pass through from phone to Mac or iPad.
Versus any other MFA system, which requires manual intervention. Yubikey - either have to read the code and type it manually OR tap the device (if you're on a laptop with an open USB port). App-based - have to open the app and copy/paste or manually enter the code. Etc.
It is socially acceptable to say you as a revenue generating customer don't know every little detail of TOTP, so the help desk for all practical purposes has to become a TOTP app help desk and provide support for every app ever written and every use case imaginable including device upgrades, etc. There is no upper limit to technical support. "Your helpdesk told me to install this app and now my battery is dead I demand compensation"
TOTP is pretty expensive to implement.
But when I try to log in, they give no indication of which one I have to use.
So I finally started annotating which one in my password manager, so it's a whole extra step to load up that as well, and then search for the app on my phone.
Except it's worse: both the Google and Microsoft authenticators are just named "Authenticator", identically. At least the Google icon is a "G", but the Microsoft icon is so generic it could literally be any company. And then the Symantec Authenticator is randomly called "VIP Access", with zero indication it's by Symantec or that it's even an authenticator.
And because I only use these things once a month or so, I'm re-baffled by it every time.
But in any case, what I wanted to let you know is that you can convert the Symantec VIP token into a standard TOTP token.
Also Square Enix though they have started letting you set up third party authenticators, I just haven't migrated yet.
Then 10 or so accounts in Aegis for general 2fa (including both Microsoft and Google, it has to be said)
There are other ways to do it that don't require using Python and the Steam API by using Steam's desktop application, but since this is HN I find this the most interesting.
But outside of work, all my personal TOTP codes are consolidated.
I really wish I could use Aegis for all of it, but I wouldn't want to use Authy for all of it.
Because whenever I'd sign up or they'd add it as a requirement, they'd always link to a specific authenticator app to use.
Is that just a suggestion rather than a requirement?
[1] https://datatracker.ietf.org/doc/html/rfc6238
[2] https://www.iana.org/assignments/uri-schemes/prov/otpauth
Although now that I'm researching it, it's even more convoluted. I'd installed the Symantec VIP Access authenticator app, for example, specifically because PayPal had said they required it (or the wording had led me to believe that -- they certainly didn't mention alternatives).
But now apparently it's the opposite -- as of this past June, PayPal has removed support for Symantec, and requires instead Google/Microsoft/Authy/etc.:
https://www.paypal.com/us/smarthelp/article/what-other-2-ste...
What in the actual hell. I swear to god there's no winning here. :S
[1] https://www.cyrozap.com/2014/09/29/reversing-the-symantec-vi... (expired cert warning)
But honestly: If the "remember this session" button is checked as it often is for apps and sites, you should only have to do it every once in a while. Or, if the site is a bit more clever, you may only have to 2FA on sensitive screens, such as "edit personal data" or "make purchase" or "transfer money".
The nice thing about "non-push" TOTP is that it does not require any external service. A site could generate its own TOTP keys, show you a QR code and let you use any app (Authy, 2FAone, Google Authenticator, etc) to manage those codes. And your phone can be offline and still work with it, and you can back up your own 2FA keys.
"Push" based 2FA requires a service, typically paid, like Okta or RSA.
Every time you change device or browser, for many services when you change your IP country, and many services limit the amount of remembered device sessions meaning you basically have to do it every day. Multiply by the number of services that force 2FA. Pray your VPN behavior or travel did not get you some hidden red flag.
The point is that it places a requirement on the user and interrupts their workflow when they just want to Get Stuff Done. And if it stops working then the burden is on the user to make it work again.
TOPT is the least worst way of doing 2FA.
I wish I lived in a world where this sort of thing wasn't necessary, but if you have a service where there are accounts that are worth a lot of money in the real world, you need to have some kind of 2FA.
Not sure of its cryptographic guarantees but one can sponge MD5 for more goodness: https://archive.is/pqFnv
That's the reason for SMS success: It is indeed incredibly easy to implement and deploy at scale.
- Our CISO is both incompetent and a poor leader.
Next question? :)
I don't actually know anyone who has gone through that, but I have no doubts that it happens.