There was a TOTP app for Pebble. I wish that platform hadn’t burned out.
I think if the app is hidden behind a button press then the shoulder-surfing risk isn’t any worse than it is on a phone app or a dedicated hardware token. A phone app is probably way more readable from a distance than a 1-inch e-ink display.
RIP. I went swimming with mine and the seal wasn’t up to it and my poor wristwatch died, but it really could do a number of neat tricks & at a fair price.
With tens to hundreds of 2FA accounts… the only sane way to utilize 2FA is just putting them in my password-manager, so they can be quickly found/selected/auto-filled.
4 2FA codes is nice…. but then they would only be for the login on my PC itself, and the password-manager unlock
2FA is for people who don’t use secure passwords. When the password is 20 random characters, used for only one purpose, and locked behind a suitable pass phrase, using a good (slow) password key derivation function, its security is orders of magnitude higher than the typical possibly reused low-entropy memorable password. Unless the security of the service is the kind of joke that stores password in plaintext, 2FA is hardly needed.
Now there’s always the fishing attack, but the only reliable way out of this one is a hardware token, which can authenticate the service you’re logging in.
Fact: for people who use one high-entropy password per service, the security benefits of 2FA are marginal.
Fact: for people who use the same low-entropy password everywhere, the security benefits of 2FA are kind of major.
Conclusion: 2FA is (mostly) for people who don’t use secure passwords. See what I mean?
You need to think about how passwords are compromised exactly:
It’s compromised by another website
It’s brute forced
It’s stored in the clear in the website’s database
It’s fished
My password is immune (1) because I use it for a single website only. It’s immune to (2) because of its high entropy (even if the website stored an unsalted fast hash of it). Finally, (3) is extremely unlikely for websites that make the effort to add 2FA.
That leaves (4), but TOTP can also be fished. Not the shared secret, but once a session is started, attackers can generally do maximum damage (some operations may be password/2FA protected, but that is so far from enough…).
My only reliable solution that actually increases security compared to a password alone, is the possession of a security token: a local procedure that can authenticate the website, as well as being authenticated by it. A software security token could be compromised if my computer is compromised or stolen, so the very best here is a hardware security token. The hardware security token might still be compromised if it is stolen by an adversary that performs power analysis, but stealing its keys won’t help if the real keys are derived from a password I input into it.
Until I have a security token I can use, I’m holding on my passwords for as long as I can.
That’s what I had in mind. Now think of the power such an attacker would have:
If they can fish me into typing my password, they can fish me into typing my TOTP code. They get in in both cases, and there’s a good chance they can change my credential right then and there (and if they do it quick and automated my TOTP code might still be valid, so they can easily change my credentials and lock me out for good).
There is no way to exploit bugs in my local software if they don’t already have meaningful control over my computer. If they do have that control, they can likely log my keystrokes and copy my database. Or failing that, intercept the clipboard and get whatever specific password I’m copying. Even if they can’t steal my TOTP recovery codes (which are most likely stored in my password database, but let’s say I’m paranoid enough to put them elsewhere), they can still log my TOTP temporary code when I’m logged in and again lock me out of my online account.
In both cases, TOTP fails to increase my security. My password manager with its local database makes TOTP utterly useless. Hardware tokens on the other hand can stop fishing attacks. Knowing that fishing is by far the bigger threat, this makes hardware tokens pretty useful.
Now there’s always the fishing attack, but the only reliable way out of this one is a hardware token, which can authenticate the service you’re logging in.
TOTP is also authenticated. You don’t just randomly enter any 6 digit code. It’s a symmetric key that both parties have. Its biggest drawback is that the key can be copied and therefore there’s no guarantee that only one party has it.
A hardware token’s biggest strength is that they can’t easily be copied. Thus, it’s something you, and only you have.
Maybe I wasn’t clear. My point here is that TOTP does not help you identify the website you’re logging in. If you’re logging in scam.example.com and failed to notice it wasn’t the real deal, checking out your phone for the relevant 6 digits won’t help you. And the scam website can then just forward all your credentials (including TOTP) to the real website and steal your identity or whatever.
Hardware tokens are different. Since they’re not passive they can perform (authenticated) key exchange with the service, and if they use a different key for each service (possibly by deriving their private key from the service’s name for instance), trying to log into the scam’s website will just cause you to use a different key, and the login will fail (or at least the scammers won’t even be able to connect you to the real website, let alone perform a real MitM attack. The best they can do is make you believe you’re logged in and trick you into leaking information while you do, but at least they won’t have your credentials.
I recall this study, by Google I think, about how 2FA affected fishing attacks. All of them reduced successful fishing attempts, but only hardware tokens completely eliminated them.
That kind of thing, yes. (I guess this fine wrist band TOTP generator technically counts as a “hardware token”, but it doesn’t use the protocols that completely stops fishing.)
Note that a properly set up phone could probably serve as a hardware token. Obviously the attack surface is much larger, but as long as the phone is unhacked it should work.
They add a time-based component. Regular passwords are practically static. Say your password gets man-in-the-middled in transit, or you type it into something that looks like your bank but isn’t. With the usual 30s TOTP expiry time, those credentials are only good for a few seconds, which limits their usefulness, as an attacker has to use them right away.
In this scenario we’re not protecting against loss of the password store, admittedly.
There was a TOTP app for Pebble. I wish that platform hadn’t burned out.
I think if the app is hidden behind a button press then the shoulder-surfing risk isn’t any worse than it is on a phone app or a dedicated hardware token. A phone app is probably way more readable from a distance than a 1-inch e-ink display.
RIP. I went swimming with mine and the seal wasn’t up to it and my poor wristwatch died, but it really could do a number of neat tricks & at a fair price.
Got a laugh out of the presence of a code for FTX in the first image!
With tens to hundreds of 2FA accounts… the only sane way to utilize 2FA is just putting them in my password-manager, so they can be quickly found/selected/auto-filled. 4 2FA codes is nice…. but then they would only be for the login on my PC itself, and the password-manager unlock
what’s the point of using 2FA if they are stored in the same place as your passwords?
2FA is for people who don’t use secure passwords. When the password is 20 random characters, used for only one purpose, and locked behind a suitable pass phrase, using a good (slow) password key derivation function, its security is orders of magnitude higher than the typical possibly reused low-entropy memorable password. Unless the security of the service is the kind of joke that stores password in plaintext, 2FA is hardly needed.
Now there’s always the fishing attack, but the only reliable way out of this one is a hardware token, which can authenticate the service you’re logging in.
this… isn’t true at all.
Fact: for people who use one high-entropy password per service, the security benefits of 2FA are marginal.
Fact: for people who use the same low-entropy password everywhere, the security benefits of 2FA are kind of major.
Conclusion: 2FA is (mostly) for people who don’t use secure passwords. See what I mean?
You can have the highest entropy password possible (lol), but it won’t help if it’s compromised… and now 2FA is a major benefit.
You need to think about how passwords are compromised exactly:
My password is immune (1) because I use it for a single website only. It’s immune to (2) because of its high entropy (even if the website stored an unsalted fast hash of it). Finally, (3) is extremely unlikely for websites that make the effort to add 2FA.
That leaves (4), but TOTP can also be fished. Not the shared secret, but once a session is started, attackers can generally do maximum damage (some operations may be password/2FA protected, but that is so far from enough…).
My only reliable solution that actually increases security compared to a password alone, is the possession of a security token: a local procedure that can authenticate the website, as well as being authenticated by it. A software security token could be compromised if my computer is compromised or stolen, so the very best here is a hardware security token. The hardware security token might still be compromised if it is stolen by an adversary that performs power analysis, but stealing its keys won’t help if the real keys are derived from a password I input into it.
Until I have a security token I can use, I’m holding on my passwords for as long as I can.
If you use a password manager, that could be compromised. Basically, do you want to put ultimate trust in your password manager? I don’t, thus 2FA.
How do you compromise KeepassXC? My password manager isn’t a website, it’s local software with a local copy of the encrypted database.
Social engineer your passphrase from you, bug in the software, etc.
That’s what I had in mind. Now think of the power such an attacker would have:
If they can fish me into typing my password, they can fish me into typing my TOTP code. They get in in both cases, and there’s a good chance they can change my credential right then and there (and if they do it quick and automated my TOTP code might still be valid, so they can easily change my credentials and lock me out for good).
There is no way to exploit bugs in my local software if they don’t already have meaningful control over my computer. If they do have that control, they can likely log my keystrokes and copy my database. Or failing that, intercept the clipboard and get whatever specific password I’m copying. Even if they can’t steal my TOTP recovery codes (which are most likely stored in my password database, but let’s say I’m paranoid enough to put them elsewhere), they can still log my TOTP temporary code when I’m logged in and again lock me out of my online account.
In both cases, TOTP fails to increase my security. My password manager with its local database makes TOTP utterly useless. Hardware tokens on the other hand can stop fishing attacks. Knowing that fishing is by far the bigger threat, this makes hardware tokens pretty useful.
TOTP is also authenticated. You don’t just randomly enter any 6 digit code. It’s a symmetric key that both parties have. Its biggest drawback is that the key can be copied and therefore there’s no guarantee that only one party has it.
A hardware token’s biggest strength is that they can’t easily be copied. Thus, it’s something you, and only you have.
Maybe I wasn’t clear. My point here is that TOTP does not help you identify the website you’re logging in. If you’re logging in
scam.example.comand failed to notice it wasn’t the real deal, checking out your phone for the relevant 6 digits won’t help you. And the scam website can then just forward all your credentials (including TOTP) to the real website and steal your identity or whatever.Hardware tokens are different. Since they’re not passive they can perform (authenticated) key exchange with the service, and if they use a different key for each service (possibly by deriving their private key from the service’s name for instance), trying to log into the scam’s website will just cause you to use a different key, and the login will fail (or at least the scammers won’t even be able to connect you to the real website, let alone perform a real MitM attack. The best they can do is make you believe you’re logged in and trick you into leaking information while you do, but at least they won’t have your credentials.
I recall this study, by Google I think, about how 2FA affected fishing attacks. All of them reduced successful fishing attempts, but only hardware tokens completely eliminated them.
Ah! So you’re talking about something more “modern” — WebAuthn and friends?
None of the hardware tokens I’ve used actually do this yet.
That kind of thing, yes. (I guess this fine wrist band TOTP generator technically counts as a “hardware token”, but it doesn’t use the protocols that completely stops fishing.)
Note that a properly set up phone could probably serve as a hardware token. Obviously the attack surface is much larger, but as long as the phone is unhacked it should work.
They add a time-based component. Regular passwords are practically static. Say your password gets man-in-the-middled in transit, or you type it into something that looks like your bank but isn’t. With the usual 30s TOTP expiry time, those credentials are only good for a few seconds, which limits their usefulness, as an attacker has to use them right away.
In this scenario we’re not protecting against loss of the password store, admittedly.