4 ms·

TOTP is falling out of fashion because the underlying crypto component is just a plaintext secret that is distributed over the Internet and stored unhashed in a

TOTP is falling out of fashion because the underlying crypto component is just a plaintext secret that is distributed over the Internet and stored unhashed in a database, probably right next to the password hashes. There's a real argument too be made that it's not a real second factor but instead more like 1.5FA.

c0l0 5y ago
Cool; when are we going to get rid of the "API key" then?
- monocasa 5y ago
  An API key is basically 1FA, not really sure why that's relevant.
deleted 5y ago
[deleted]
briHass 5y ago
The storage of the secret on the server side isn't really relevant to the major wins that TOTP provides. A well-done implementation stops keyloggers and shoulder surfers, and for many people that aren't using password managers, it does add a significant level of security, without greatly inconveniencing the user. Honestly, the alternatives are worse. For U2F keys, you need to remember to bring your dongle with you, it has bad support on phones/mobile devices, some machines lock down ports, and there's a not-insignificant cost to buy.
- monocasa 5y ago
  U2F keys aren't the only other option. Treating phones as a always connected hardware dongle with an app is another option. There are others as well. Hardware tokens talking U2F/FIDO are just the only standards compliant option that can be implemented totally in browser.
BoardsOfCanada 5y ago
Had to look it up and you're correct. Why on earth isn't it based on public key cryptography?
- UncleMeat 5y ago
  The backend needs to be able to produce the same code that you produce. If somebody could do that with a public key then you’d need to keep the public key a secret. If you want to do it with a protocol that enables signed messages and other stuff then the UX cannot be “type in a few numbers.”
  - BoardsOfCanada 5y ago
    I don't see why it would have to be more numbers to type in than in the symmetric case. And yes, the public key would be the secret. Seems like a strict improvemebt on the way it currently works.
    - UncleMeat 5y ago
      If the public key needs to be a secret then it is the same as it is now. If the attacker obtains either secret they win. The whole point of asymmetric crypto is that the public key doesn’t need to be kept secret.
      - BoardsOfCanada 5y ago
        Maybe I didn't express myself very well. The server stores the public key, instead of the current symmetric secret. So the new "secret" is the public key. It could be published of course but there is zero point to do so. So now if the database is exfiltrated by a hacker without anyone noticing, he still couldn't produce tokens to log in as a user.
        UncleMeat 5y ago
        > So now if the database is exfiltrated by a hacker without anyone noticing, he still couldn't produce tokens to log in as a user. Why not? With TOTP, you type in a short code. The server needs to also be able to generate this code so they can verify that your code is correct. If it only has the public key then it must be able to produce the tokens to login as the user. If you want a more complex setup where the public key can only verify that the code is valid but cannot be used to create valid codes then the codes themselves (and the protocol) become considerably more complex and aren't going to be managed by a "type six digits into a web form" UX. I also don't think this really matters in a major sense. If somebody pwns the credential database then continuing to rely on authentication to prevent further harm is a fool's errand. "The adversary only got to extract the credential database and achieved nothing else" is not an especially common scenario today.
unqueued 5y ago
I really disagree with this idea. It reminds me of how developers try to prevent you from pasting passwords into password fields. The benefit of using TOTP at all far outweighs the insecurity of storing it on the same computer. And it is so low effort, I use it everywhere possible. I have a simple script that takes a screenshot, uses zbarimg to extract the single line otpauth:// string, and appends it to my pass password database[1], which then hooks back into my browser. I somehow don't think I would bother with a hardware key for my BestBuy.com account. Besides, my password db is itself is encrypted with GPG, and GPG can use a hardware token to be unlocked, thereby giving you more flexibility and transparency, while still benefiting from a token. Developers can't know what configuration users have. [1]: https://www.passwordstore.org/ https://www.passwordstore.org/
tptacek 5y ago
I don't think there's any validity to this. TOTP is falling out of fashion because it's not phishing-resistant, and, more importantly, because it has poor UX for ordinary users. This "plaintext secret" stuff has nothing to do with it.
- monocasa 5y ago
  I mean, I was a engineer that participated in those discussions when I worked at an IDP firm. The concern that if we got popped and the password database was leaked somehow, that with TOTP the attackers had everything to start logging in as users who had weak passwords but with public/private schemes they didn't. This was a very real concern that affected preference for public/private schemes (which included hardware tokens), and engineering effort to decrease the UX burden of hardware tokens specifically. You might correctly call that concern more focused on CYA of the the firm itself, but I think that's not the worse thing in the world, and the underlying crypto primitives certainly played a role here.
  - tptacek 5y ago
    This doesn't even make sense as an objection. If you get popped, attackers are going to log in with whatever credentials you don't revoke. You're simply going to revoke all your 2FA credentials; retaining them, no matter what scheme was used to store them, would be malpractice. Meanwhile: WebAuthn (nee U2F) was literally introduced as an anti-phishing tool --- not as a database protection technology. They did U2F because people kept getting phished with code-generator authentication. The problem with TOTP is that it doesn't have a mechanism to authenticate the site asking for the code.
    - monocasa 5y ago
      Yes, you would revoke them as soon as you realize, but until you realize (and practically there's generally a delta there for a successful attack) in public key schemes of 2FA the attacker doesn't have enough to login as those users since they only have those user's public keys. For TOTP they very well might have everything they need for weak passwords. If you can trend towards public key based schemes there's real benefits from the IDPs prespective. Yes TOTP wasn't designed to help here, but from the IDP's perspective that just means that you should gently shift users to 2FA schemes that do provide those semantics. And U2F/FIFO is not the only other option here, just the only one that can be implemented totally in browser for the client. Duo's phone push notifications are public key crypto under the hood for one example.
jrochkind1 5y ago
what's your preferred better option(s)? Just hardware keys? (Other comments in this thread seem to be suspicious of hardware keys too!)
- monocasa 5y ago
  An app on a phone that uses the security module like how Duo works is nice for most use cases, and FIDO/U2F dongles work well for the vast maority of remaining use cases.
necovek 5y ago
By that account, passwords are exactly the same, so it's not even 1.5FA but only 1FA with each being 0.5FA. Point of something being a second factor is for it to be something physically distinct from the first factor, and something different in the "something you know, something you are, something you have". As long as you keep your TOTP device and password manager separate, they provide all the guarantees a second factor should. As a bonus, they also provide one-time use tokens (both HOTP and TOTP, though HOTP is more susceptible to pre-generation of tokens to be used later), thus protecting against eavesdropping and people looking over your shoulder (or recording you). As such, I don't buy the argument for TOTP not being a second factor auth at all.
- monocasa 5y ago
  Passwords and TOTP are both something you know. And there are children comments here talking about how it's fine, they keep their TOTP keys in the same password database.
  - necovek 5y ago
    They are both "something you know" only if you keep them on the same device. Yes, there are comments of people using them here that way. At my previous job, even a security IT guy did not find that an issue when I brought it up how people automated 2FA for CLI scripts. In that case, they are not even 1.5FA, they are strictly 1FA password-authentication (jumping through a few hoops to get all "components" of a password, but it's a single password protecting access). If they are separate devices and you don't really remember your key, they are hardly something you know, IMO, so I disagree there. In a sense, you could also extract the base cryptographic key of any hardware token (or the producer of the token might have it), and it's also "something you know", which is why I disagree. It's just trivial to extract this key for TOTP, but extraction is a separate step IMO.
timwis 5y ago
No…surely totp uses asymmetric cryptography, right?
- monocasa 5y ago
  The codes are the last six decimal digits of an hmac over the key and the current time (rounded to some boundary, generally 30 seconds). The QR code is the account's metadata and the preshared key.

c0l0 5y ago

Cool; when are we going to get rid of the "API key" then?

monocasa 5y ago
An API key is basically 1FA, not really sure why that's relevant.

deleted 5y ago

[deleted]

briHass 5y ago

The storage of the secret on the server side isn't really relevant to the major wins that TOTP provides. A well-done implementation stops keyloggers and shoulder surfers, and for many people that aren't using password managers, it does add a significant level of security, without greatly inconveniencing the user. Honestly, the alternatives are worse. For U2F keys, you need to remember to bring your dongle with you, it has bad support on phones/mobile devices, some machines lock down ports, and there's a not-insignificant cost to buy.

monocasa 5y ago
U2F keys aren't the only other option. Treating phones as a always connected hardware dongle with an app is another option. There are others as well. Hardware tokens talking U2F/FIDO are just the only standards compliant option that can be implemented totally in browser.

BoardsOfCanada 5y ago

Had to look it up and you're correct. Why on earth isn't it based on public key cryptography?

UncleMeat 5y ago
The backend needs to be able to produce the same code that you produce. If somebody could do that with a public key then you’d need to keep the public key a secret. If you want to do it with a protocol that enables signed messages and other stuff then the UX cannot be “type in a few numbers.”
- BoardsOfCanada 5y ago
  I don't see why it would have to be more numbers to type in than in the symmetric case. And yes, the public key would be the secret. Seems like a strict improvemebt on the way it currently works.
  - UncleMeat 5y ago
    If the public key needs to be a secret then it is the same as it is now. If the attacker obtains either secret they win. The whole point of asymmetric crypto is that the public key doesn’t need to be kept secret.
    - BoardsOfCanada 5y ago
      Maybe I didn't express myself very well. The server stores the public key, instead of the current symmetric secret. So the new "secret" is the public key. It could be published of course but there is zero point to do so. So now if the database is exfiltrated by a hacker without anyone noticing, he still couldn't produce tokens to log in as a user.
      - UncleMeat 5y ago
        > So now if the database is exfiltrated by a hacker without anyone noticing, he still couldn't produce tokens to log in as a user. Why not? With TOTP, you type in a short code. The server needs to also be able to generate this code so they can verify that your code is correct. If it only has the public key then it must be able to produce the tokens to login as the user. If you want a more complex setup where the public key can only verify that the code is valid but cannot be used to create valid codes then the codes themselves (and the protocol) become considerably more complex and aren't going to be managed by a "type six digits into a web form" UX. I also don't think this really matters in a major sense. If somebody pwns the credential database then continuing to rely on authentication to prevent further harm is a fool's errand. "The adversary only got to extract the credential database and achieved nothing else" is not an especially common scenario today.

unqueued 5y ago

I really disagree with this idea. It reminds me of how developers try to prevent you from pasting passwords into password fields. The benefit of using TOTP at all far outweighs the insecurity of storing it on the same computer. And it is so low effort, I use it everywhere possible. I have a simple script that takes a screenshot, uses zbarimg to extract the single line otpauth:// string, and appends it to my pass password database[1], which then hooks back into my browser. I somehow don't think I would bother with a hardware key for my BestBuy.com account. Besides, my password db is itself is encrypted with GPG, and GPG can use a hardware token to be unlocked, thereby giving you more flexibility and transparency, while still benefiting from a token. Developers can't know what configuration users have. [1]: https://www.passwordstore.org/ https://www.passwordstore.org/

tptacek 5y ago

I don't think there's any validity to this. TOTP is falling out of fashion because it's not phishing-resistant, and, more importantly, because it has poor UX for ordinary users. This "plaintext secret" stuff has nothing to do with it.

monocasa 5y ago
I mean, I was a engineer that participated in those discussions when I worked at an IDP firm. The concern that if we got popped and the password database was leaked somehow, that with TOTP the attackers had everything to start logging in as users who had weak passwords but with public/private schemes they didn't. This was a very real concern that affected preference for public/private schemes (which included hardware tokens), and engineering effort to decrease the UX burden of hardware tokens specifically. You might correctly call that concern more focused on CYA of the the firm itself, but I think that's not the worse thing in the world, and the underlying crypto primitives certainly played a role here.
- tptacek 5y ago
  This doesn't even make sense as an objection. If you get popped, attackers are going to log in with whatever credentials you don't revoke. You're simply going to revoke all your 2FA credentials; retaining them, no matter what scheme was used to store them, would be malpractice. Meanwhile: WebAuthn (nee U2F) was literally introduced as an anti-phishing tool --- not as a database protection technology. They did U2F because people kept getting phished with code-generator authentication. The problem with TOTP is that it doesn't have a mechanism to authenticate the site asking for the code.
  - monocasa 5y ago
    Yes, you would revoke them as soon as you realize, but until you realize (and practically there's generally a delta there for a successful attack) in public key schemes of 2FA the attacker doesn't have enough to login as those users since they only have those user's public keys. For TOTP they very well might have everything they need for weak passwords. If you can trend towards public key based schemes there's real benefits from the IDPs prespective. Yes TOTP wasn't designed to help here, but from the IDP's perspective that just means that you should gently shift users to 2FA schemes that do provide those semantics. And U2F/FIFO is not the only other option here, just the only one that can be implemented totally in browser for the client. Duo's phone push notifications are public key crypto under the hood for one example.

jrochkind1 5y ago

what's your preferred better option(s)? Just hardware keys? (Other comments in this thread seem to be suspicious of hardware keys too!)

monocasa 5y ago
An app on a phone that uses the security module like how Duo works is nice for most use cases, and FIDO/U2F dongles work well for the vast maority of remaining use cases.

necovek 5y ago

By that account, passwords are exactly the same, so it's not even 1.5FA but only 1FA with each being 0.5FA. Point of something being a second factor is for it to be something physically distinct from the first factor, and something different in the "something you know, something you are, something you have". As long as you keep your TOTP device and password manager separate, they provide all the guarantees a second factor should. As a bonus, they also provide one-time use tokens (both HOTP and TOTP, though HOTP is more susceptible to pre-generation of tokens to be used later), thus protecting against eavesdropping and people looking over your shoulder (or recording you). As such, I don't buy the argument for TOTP not being a second factor auth at all.

monocasa 5y ago
Passwords and TOTP are both something you know. And there are children comments here talking about how it's fine, they keep their TOTP keys in the same password database.
- necovek 5y ago
  They are both "something you know" only if you keep them on the same device. Yes, there are comments of people using them here that way. At my previous job, even a security IT guy did not find that an issue when I brought it up how people automated 2FA for CLI scripts. In that case, they are not even 1.5FA, they are strictly 1FA password-authentication (jumping through a few hoops to get all "components" of a password, but it's a single password protecting access). If they are separate devices and you don't really remember your key, they are hardly something you know, IMO, so I disagree there. In a sense, you could also extract the base cryptographic key of any hardware token (or the producer of the token might have it), and it's also "something you know", which is why I disagree. It's just trivial to extract this key for TOTP, but extraction is a separate step IMO.

timwis 5y ago

No…surely totp uses asymmetric cryptography, right?

monocasa 5y ago
The codes are the last six decimal digits of an hmac over the key and the current time (rounded to some boundary, generally 30 seconds). The QR code is the account's metadata and the preshared key.