6 ms·

What confuses me is that TOTP is usually referred to as "something you have" (the app on your smartphone, with the secret), as opposed to "something you know" (

by margo209320 6y ago

What confuses me is that TOTP is usually referred to as "something you have" (the app on your smartphone, with the secret), as opposed to "something you know" (your password). But the TOTP algorithm and the current time is known to any attacker. What remains, is just the secret, which is the same as a password (a password given to you by the service provider instead of a self-chosen one). So in the end, TOTP just increases password complexity, doesn't it? EDIT Trying to answer my question: it prevents a MITM attacker from sniffing your password hash once and using that forever, since the TOTP code is different each time and the attacker would still need to brute-force the secret. But if that's the only benefit of using TOTP, couldn't that be combined with the password: The service where I want to authenticate sends me a "challenge" (random number), I enter my password and an algorithm on my client combines the challenge and my password-hash to create the result to send back to the service. This way the value sent over the insecure line is always different, since it is based on the challenge. The user would not have the added inconvenience of having to enter the TOTP code.

Lex-2008 6y ago
What you explained in EDIT, reminds me of HTTP Digest auth: https://stackoverflow.com/questions/2384230/what-is-digest-authentication https://stackoverflow.com/questions/2384230/what-is-digest-a...
metafunctor 6y ago
Kind of, but TOTP differs from passwords in important ways. Unlike user-selected passwords, the TOTP secret is guaranteed to be unique and strong as it's generated by the server. Observing some TOTP codes doesn't reveal the secret, so even if the password leaks the TOTP secret probably remains safe. Finally, the TOTP secret is typically managed in a device separate from the one where the TOTP code is entered, making it harder to steal.
- earthboundkid 6y ago
  I think you can get most of the advantages by just assigning users their passwords. Users either have a password manager to store the assigned password in, or they’re totally insecure and can’t be trusted to make up a password. Either way, just assign something random to them.
  - GoblinSlayer 6y ago
    It's not all that difficult to remember a strong password, and if you use it with pwdhash, it's unbreakable.
    - SAI_Peregrinus 6y ago
      But you need multiple strong passwords for (almost) every site. You need at least one to start, and when one of those sites inevitably leaks all of its passwords you'll have to change that one. Also 50% or more of the sites will have incompatible password content rules, so you'll have to work around that. Password managers are a lot easier than trying to keep the state for a deterministic system. They're just as unbreakable with a good master password, and actually work with real-world site's rules around passwords.
      - GoblinSlayer 6y ago
        See how it works: https://pwdhash.github.io/website/ https://pwdhash.github.io/website/ - the master password is hashed with the site name, you supply the resulting hash as the password, you can't reverse this hash if the master password is strong. The result has uppercase letters and lowercase letters and digits, which is good enough for most sites. In practice I saw one site restricting password length to 16 chars, but in case of a hash 16 chars are decent: they contain 95 bits of entropy. And saw one site requiring fourth complexity - punctuation characters - this is easy to circumvent by adding a minus at the end, you can store this information in the open, since circumvention of password policy doesn't affect password strength.
        SAI_Peregrinus 6y ago
        I know how it works. It doesn't help the issues I listed. You can't change passwords when required without storing a database of site names & increments (or similar) to allow you to get the right password. So it's not stateless, and you may as well get all the other benefits of a properly encrypted storage database (autofill, metadata, storing extra things like TOTP keys, SSH keys, etc).
- GoblinSlayer 6y ago
  Remember reddit app? Typically TOTP secret is used on the same device, where TOTP code and password are entered (phoneposting).
ozim 6y ago
TOTP is not U2F so it is not something you have, U2F is a setup with physical keys, you can have in android U2F module nowadays, but that is not TOTP. Keys like yubi also store TOTP secrets but that still is not U2F. TOTP is 2FA so only a second factor, which is different device so you don't have your password and secret key on the same device. With your after edit scenario password can be stolen via keylogger and if you have secret on your mobile phone or just other it is a lot harder to compromise all the devices person has. Where compromising one laptop is of course a lot easier. Secret key is sent over the network only once when you set up your 2FA and is on different device. It is also generated randomly with really long key so brute forcing it is not feasible at all. If you take into account that nowadays most passwords are available via leaked databases and attacks are just reusing already cracked weak passwords TOTP adds real value. Because even if you steal database with secret keys you are not going to be able to use it for other accounts that single person has. In the end generating new key and just scanning QR code is IMO great user experience, to change that secret key you don't have to "come up with yet another password". Where ideally you should generate your passwords with password manager a lot of people don't do this. If you generate different password for each site with password manager you probably don't need 2FA that much.
- margo209320 6y ago
  [...] with really long key so brute forcing it is not feasible at all. When setting up MFA for a Microsoft Azure AD account, they use a 9 digit code as the secret, which you can either enter manually or by scanning a QR code. My gut feeling is that 1 billion possibilities is not that hard to brute-force. I don't know if that is standard or if other services use longer secrets.
  - tialaramex 6y ago
    That's too small. Are you sure it's correct? Google Authenticator often uses 80-bit keys which is not really ideal but unlikely to be a practical attack avenue. But a billion possibilities is too small.
    - 6y ago
fanf2 6y ago
There are a number of challenge-response authentication systems, e.g. in my first job after university we used cryptocards: https://www.linuxjournal.com/article/8252 https://www.linuxjournal.com/article/8252 And my bank used to supply a similar (but smaller) authentication keypad - they now use a smartphone app instead. The “know” vs “have” question in multifactor auth traditionally assumes the thing you know is memorized (which you can’t expect people to do with TOTP secrets) and the thing you have is a physical device that authenticates itself with an embedded secret. There’s an intermediate category of secrets you have access to (e.g. in a password manager) but which can’t protect themselves against copying by the authorised user like a physical token. TOTP and HOTP were designed to be implemented in physical tokens (similar to SecureID https://en.wikipedia.org/wiki/RSA_SecurID https://en.wikipedia.org/wiki/RSA_SecurID tho that uses a different algorithm) but they are often supported by password managers or apps that allow the OTP secrets to be copied.
deleted 6y ago
[deleted]

Lex-2008 6y ago

What you explained in EDIT, reminds me of HTTP Digest auth: https://stackoverflow.com/questions/2384230/what-is-digest-authentication https://stackoverflow.com/questions/2384230/what-is-digest-a...

metafunctor 6y ago

Kind of, but TOTP differs from passwords in important ways. Unlike user-selected passwords, the TOTP secret is guaranteed to be unique and strong as it's generated by the server. Observing some TOTP codes doesn't reveal the secret, so even if the password leaks the TOTP secret probably remains safe. Finally, the TOTP secret is typically managed in a device separate from the one where the TOTP code is entered, making it harder to steal.

earthboundkid 6y ago
I think you can get most of the advantages by just assigning users their passwords. Users either have a password manager to store the assigned password in, or they’re totally insecure and can’t be trusted to make up a password. Either way, just assign something random to them.
- GoblinSlayer 6y ago
  It's not all that difficult to remember a strong password, and if you use it with pwdhash, it's unbreakable.
  - SAI_Peregrinus 6y ago
    But you need multiple strong passwords for (almost) every site. You need at least one to start, and when one of those sites inevitably leaks all of its passwords you'll have to change that one. Also 50% or more of the sites will have incompatible password content rules, so you'll have to work around that. Password managers are a lot easier than trying to keep the state for a deterministic system. They're just as unbreakable with a good master password, and actually work with real-world site's rules around passwords.
    - GoblinSlayer 6y ago
      See how it works: https://pwdhash.github.io/website/ https://pwdhash.github.io/website/ - the master password is hashed with the site name, you supply the resulting hash as the password, you can't reverse this hash if the master password is strong. The result has uppercase letters and lowercase letters and digits, which is good enough for most sites. In practice I saw one site restricting password length to 16 chars, but in case of a hash 16 chars are decent: they contain 95 bits of entropy. And saw one site requiring fourth complexity - punctuation characters - this is easy to circumvent by adding a minus at the end, you can store this information in the open, since circumvention of password policy doesn't affect password strength.
      - SAI_Peregrinus 6y ago
        I know how it works. It doesn't help the issues I listed. You can't change passwords when required without storing a database of site names & increments (or similar) to allow you to get the right password. So it's not stateless, and you may as well get all the other benefits of a properly encrypted storage database (autofill, metadata, storing extra things like TOTP keys, SSH keys, etc).
GoblinSlayer 6y ago
Remember reddit app? Typically TOTP secret is used on the same device, where TOTP code and password are entered (phoneposting).

ozim 6y ago

TOTP is not U2F so it is not something you have, U2F is a setup with physical keys, you can have in android U2F module nowadays, but that is not TOTP. Keys like yubi also store TOTP secrets but that still is not U2F. TOTP is 2FA so only a second factor, which is different device so you don't have your password and secret key on the same device. With your after edit scenario password can be stolen via keylogger and if you have secret on your mobile phone or just other it is a lot harder to compromise all the devices person has. Where compromising one laptop is of course a lot easier. Secret key is sent over the network only once when you set up your 2FA and is on different device. It is also generated randomly with really long key so brute forcing it is not feasible at all. If you take into account that nowadays most passwords are available via leaked databases and attacks are just reusing already cracked weak passwords TOTP adds real value. Because even if you steal database with secret keys you are not going to be able to use it for other accounts that single person has. In the end generating new key and just scanning QR code is IMO great user experience, to change that secret key you don't have to "come up with yet another password". Where ideally you should generate your passwords with password manager a lot of people don't do this. If you generate different password for each site with password manager you probably don't need 2FA that much.

margo209320 6y ago
[...] with really long key so brute forcing it is not feasible at all. When setting up MFA for a Microsoft Azure AD account, they use a 9 digit code as the secret, which you can either enter manually or by scanning a QR code. My gut feeling is that 1 billion possibilities is not that hard to brute-force. I don't know if that is standard or if other services use longer secrets.
- tialaramex 6y ago
  That's too small. Are you sure it's correct? Google Authenticator often uses 80-bit keys which is not really ideal but unlikely to be a practical attack avenue. But a billion possibilities is too small.
  - 6y ago

fanf2 6y ago

There are a number of challenge-response authentication systems, e.g. in my first job after university we used cryptocards: https://www.linuxjournal.com/article/8252 https://www.linuxjournal.com/article/8252 And my bank used to supply a similar (but smaller) authentication keypad - they now use a smartphone app instead. The “know” vs “have” question in multifactor auth traditionally assumes the thing you know is memorized (which you can’t expect people to do with TOTP secrets) and the thing you have is a physical device that authenticates itself with an embedded secret. There’s an intermediate category of secrets you have access to (e.g. in a password manager) but which can’t protect themselves against copying by the authorised user like a physical token. TOTP and HOTP were designed to be implemented in physical tokens (similar to SecureID https://en.wikipedia.org/wiki/RSA_SecurID https://en.wikipedia.org/wiki/RSA_SecurID tho that uses a different algorithm) but they are often supported by password managers or apps that allow the OTP secrets to be copied.

deleted 6y ago

[deleted]