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)
This is not always true either. If you have limited control over the timestamp fed to a TOTP app you can capture codes that will be valid at any time of your choosing in the future. TOTP codes are just a magic hash of a secret and a timestamp.
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.
I just posted something for free on FB marketplace. Someone almost immediately contacted me via FB messenger "interested" in my item. They asked me to txt them (area code was same as my city). I texted them.
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.
Can you close the loop on this for me? Presumably they still would have required your password to do something nefarious, so I do not understand how they potentially profit from this.
¯\_(ツ)_/¯, your comment was originally flagged and has been made alive again.
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.
You'll need to implement views for handling recovery tokens, processes for people losing their second factor due to stolen phone or corrupted app, and FAQ pages for questions about why my second factor is not accepted.
This 100%. Yes those functions are easy but that isn't the issue with 2fa, it's the people. I just had a customer send in a ticket that their account from 3 years ago had 2fa enabled. They didn't remember setting that up, clearly had a new phone since then. These quick clickbait articles never bring up those subjects and how to properly address them.
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.
An email-based password+2FA reset loop is an option. The major motivator for 2FA is preventing replay of captured credentials for your own app, leaving out-of-band authentication permissible. Just hope the user didn't use the same password for your app and their email.
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.
Bingo. The support cost of MFA, especially non-SMS methods where some of the recovery process is delegated to the mobile operator, is the top-level bit.
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 :)
Google Authenticator AFAIK doesn't even let you backup the codes. When your phone is lost or breaks, you have to reset every account by some other way.
Use Authy, 2faone or any other totp tool than google authenticator. Shame on Google, honestly, for not enabling a backup mechanism for that. If you can’t do it right, don’t do it at all.
>You'll need to implement [...] , processes for people losing their second factor due to
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.
So, yes, I suppose a good totp article would cover the user experience as well. But just because some places implement it poorly does not mean it is a bad idea.
You also need more than just a yes/no just for the authentication.
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.
Time drift is the clients responsibility. You’re letting perfect be the enemy of good - very few people use fully offline devices for years at a time, and if you’re not a bank, even something like a 2-5 minute diff is tolerable.
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 much better than SMS. And it’s much easier to implement than SMS as well.
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.
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.
When you use Bitwarden to fill in credentials, it also copies the TOTP code automatically for that account. I find it quite convenient most of the time.
Generally the justification is "hey, we offer one form of 2FA, that's pretty good. This TOTP thing is for paranoid nerds." Bosses see it as extra work for ~no gain, what's the point? You can explain the technical superiority of the approach until you're blue in the face but they see it as just another way to do what's already implemented.
This! There is no additional security for aware users with MFA. Make MFA turned on by default, ok, but for god's sake if you provide only SMS-based 2FA, allow it to be disabled.
This. Banks have to cater to customers with all levels of technical abilities for compliance, plus they may rely on older on-prem IAM systems that don't support TOPT.
Its not socially acceptable to say in public that you don't know how to text, so SMS 2FA has zero help desk support costs.
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"
My excuse is I hate using TOTP. Stop making me open an app, wait for it to load, read numbers, type it in. If you have a situation where you have to auth multiple times, it's even more annoying. Other modern methods are less annoying and (arguably) more secure.
Not only that, but I have three authenticator apps installed because each service only works with one (or select ones).
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.
I’m not sure what the three are, but I was able to use Authy for all of my TOTP codes before I moved them all to the iOS/macOS keychain which now has TOTP support combined with autofill into the TOTP field in Safari.
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.
You can have your Steam guard in your 2FA app as long as it has support for it. I'm personally using Aegis and have managed to put the Steam TOTP there. [1]
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.
Oh right, Duo. Those are apparently OATH HOTP codes with some propriety modifications[1]. I also have to use Duo for work but almost all of the time I acknowledge the push notification instead of use the code. Between Okta, Duo, Touch ID and a Yubikey it feels like I’m having to authenticate one way or another dozens of times a day, so I feel your pain there.
But outside of work, all my personal TOTP codes are consolidated.
I myself use Aegis for almost everything, but have to use Authy for SendGrid and Twilio (those and Authy are from the same company). Then I also need Duo for my company's SSO.
I really wish I could use Aegis for all of it, but I wouldn't want to use Authy for all of it.
You don't need both Google and Microsoft Authenticators though, both of them support TOTP. But, yeah, there are some places that require as separate app just for them, like Steam, eBay, Twitch and Blizzard, which is annoying.
Most frequently, yes! Sometimes the UI crosses the line from providing a suggestion to straight up bullshitting you, but most implementations of time-based 2FA are compatible with RFC 6238[1] (of which TFA is a good summary) and communicate the shared secret in a de facto standard URI format[2] inside a bog-standard QR code.
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.:
Never interacted with Symantec’s system and thought it was one of the rare non-standard exceptions, but apparently it’s just normal TOTP with extra funky lock-in at the enrolment stage[1,2].
Yes, it's usually just a suggestion. Most sites will work with any standard TOTP app (MS Authenticator, Google Authenticator, AndOTP, Authy, etc). I have all of them in AndOTP (apart from the ones I mentioned above).
Bitwarden can generate TOTPs that get copied to your clipboard after filling the username and password box for a website. Usually all that's required is an extra ctrl-v and enter.
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.
Have your password manager take care of TOTPs. Copy and paste. You're using a password manager with randomized passwords for your sites, services, and apps, right?
And you could do it with pencil and paper if you wanted. If you were very quick at maths.
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.
That's true of any authentication mechanism. It works until it doesn't. If you wanted to work this into a traditional terminal workflow "generateToken my.host && ssh my.host"
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.
This reminds me of the one time someone tried to get me to implement TOTP in an environment without an implementation of HMAC-SHA1 (or SHA1 itself for that matter). There was also no easy way of implementing HMAC-SHA1. While protesting the insanity of the situation I produced a hacked together implementation using MD5 (which was, somehow, available).
I think they mean "at scale" to refer to a large number of users. Any service with a significantly large number of users is going to have a lot of people with limited technical aptitude that can't setup 2FA, lose access when changing their phones, etc.
I hardly blame the users though. If you actually have a certain amount of 2FA methods, the order in which they want to be migrated is often contradicting. So for some of them what you should do (according to docs): Unlink 2FA, migrate phone, link 2FA. For others you can spend an hour searching their docs and there's nothing - and then you find out that you should set up 2FA on the new phone and then somehow recover. It's aggravating, really. Then there are some where you just hope for the best because no docs exist at all.
I wasn't trying to blame the users. It's more a situation that you have to spend time managing. Many of the problems and situations can be understood ahead of time, but people avoid the early investments needed to smooth them out ending up in the situation you described. People that do recognize the issues get waved away or asked to work on "higher priority" items because it's viewed as manageable by the support team. It's really a core user experience issue.
2FA isn't some app. It's an idea. That multiple and different forms of authentication increase security. You can't just get rid of one of the factors. You at least have to replace it with another form. So yeah you can have password + totp, but if you get rid of password then you just have single factor and have lowered your security.
This doesn't exactly answer your first question, but WebAuthn exists as part of the FIDO2 framework. One of the authentication modes it provides is passwordless authentication where all you need to log in is your hardware token like YubiKey or platform token like Apple/Google Passkeys.
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.