5 ms·

What makes this 2FA? It's "something you know, plus mental labor", which makes it a password. 2FA is "something you have" (or ".. you are", for biometrics): it

by crote 10mo ago

What makes this 2FA? It's "something you know, plus mental labor", which makes it a password. 2FA is "something you have" (or ".. you are", for biometrics): it is supposed to prove that you currently physically posses the single copy of a token. The textbook example is a TOTP stored in a Yubikey. Granted, this has been watered down a lot by the way-too-common practice of storing TOTP secrets in password managers, but that's how it is supposed to work. Does your mTOTP prove you own the single copy? No, you could trivially tell someone else the secret key. Does it prove that you currently own it? No, you can pre-calculate a verification token for future use. I still think it is a very neat idea on paper, but I'm not quite seeing the added value. The obvious next step is to do all the math in client-side code and just have the user enter the secret - doing this kind of mental math every time you log in is something only the most hardcore nerds get excited about.

brna-2 10mo ago
Time based skew makes it a changeable second factor, additional changeable pass makes it the second factor, Also - if the first factor is a password manager or ssh key - this is the second factor. The idea of it was so neat to me, I just had to thinker with it.
ulrikrasmussen 10mo ago
In practice most TOTP implementation also do not prove that you have a device which is the sole owner of the secret. Except for proprietary app-based solutions the usual protocol is to display a QR code which just encodes the secret in plain text. As long as you never enter the secret anywhere but only do the computation is your head, this is just using your brain as the second factor. I would not call this a password since it is not used in the same way. Passwords are entered in plain text into fields that you trust, but that also means that passwords can be stolen. This proves that you are in possession of your brain.
- swiftcoder 10mo ago
  > Passwords are entered in plain text into fields that you trust, but that also means that passwords can be stolen The only difference here is that you are hashing the password in your head, instead of trusting the client to hash it for you before submitting it to the server. Which makes the threat model here what, exactly? Keyloggers, or login pages that use outdated/insecure methods to authenticate with the server?
  - ulrikrasmussen 10mo ago
    Yes, but also plain guessing since passwords are usually chosen by the user and not generated by the server like TOTP secrets. Also phishing attacks tricking users into entering their passwords in fake login pages, and stolen password databases.
    - swiftcoder 10mo ago
      > Yes, but also plain guessing since passwords are usually chosen by the user and not generated by the server like TOTP secrets. If we were talking a >256-bit secret, I'd buy this, but in the human-calculated case I don't see how it actually helps with this, because you've substituted a ~8 character password for a 6 digit number, which is significantly less search space to brute-force. > Also phishing attacks tricking users into entering their passwords in fake login pages yes, this is more-or-less a subset of the "keylogger/insecure login page" case > and stolen password databases There's still a server-side TOTP secret database to be stolen, no? And normally that would be hard to reverse-engineer the actual secret from, but again, you've shrunk the search space down to 1,000,000 entries, which is trivial to brute force.
rcxdude 10mo ago
The single copy part would be a lot more common if it was widely supported to have multiple tokens registered to an account. And the main point (though I agree that it doesn't make it 2FA), is to not have the secret be disclosed when you prove that you have it, which is what TOTP also achieves, which makes phishing or sniffing it significantly less valuable.
- crote 10mo ago
  Are there any mainstream websites which only allow a single TOTP token to be enrolled? I can't remember having ever run into that issue. I do recall it occasionally being an issue with Passkeys, though. The non-disclosure is indeed neat, but the same can be achieved with a password. For example: generate public/private keypair on account creation. Encrypt private key with user password. Store both on server. On auth, client downloads encrypted priv key, decrypts it with user-entered password, then signs nonce and provides it to server as proof of knowledge of user password.
  - fc417fc802 10mo ago
    You don't need to involve a private key there. Modern password authentication algorithms never reveal the bare secret (outside of initial registration ofc). For example, PAKE uses Diffie-Hellman coupled with the (salted) password hash to independently derive the same session key on both sides of the connection. AFAIK the primary technical concerns are insecure storage by the server (bad hash or salt) or keylogging of the client device. But the real issue is the human factor - ie phishing. As long as the shared secret can't be phished it solves the vast majority of real world problems. Point being, TOTP on a rooted phone handled by a FOSS password manager app whose secret store the end user retains full access to will successfully prevent the vast majority of real world attacks. You probably shouldn't use a FOSS password manager on a rooted device for your self hosted crypto wallet though.
    - crote 10mo ago
      Ah, of course! I did initially consider DH as example, but discounted it because of the need for the server to store the plaintext password - the fact that you can just hash it first completely slipped my mind. I completely agree about phishing being the main attack vector. However, I do think malware is a not-too-distant second - which makes having a single device contain both your password and TOTP secret a Really Bad Idea. Having not-perfectly-secure TOTP codes only your phone and a password manager DB only on your desktop is a pretty decent solution for that.
fxj 10mo ago
TOTP is also just password + some computation. So where is the difference? There is a lot of security theatre around TOTP with the QR code and then need of an app but you can write a 8 liner in python that does the same when you extract the password out of the QR code. import base64 import hmac import struct import time def totp(key, time_step=30, digits=6, digest='sha1'): key = base64.b32decode(key.upper() + '=' \* ((8 - len(key)) % 8)) counter = struct.pack('>Q', int(time.time() / time_step)) mac = hmac.new(key, counter, digest).digest() offset = mac[-1] & 0x0f binary = struct.unpack('>L', mac[offset:offset+4])[0] & 0x7fffffff return str(binary)[-digits:].zfill(digits) https://dev.to/yusadolat/understanding-totp-what-really-happens-when-you-generate-that-6-digit-code-1ael https://dev.to/yusadolat/understanding-totp-what-really-happ...
- crote 10mo ago
  You are supposed to store the password in a Secure Enclave, which you can only query for the current token value. You are also supposed to immediately destroy the QR code after importing it. As I already mentioned, the fact that people often use it wrong undermines its security, but that doesn't change the intended outcome.
  - alt227 10mo ago
    IMO if it is possible to use a system wrongly which undermines its security, it is already broken.
    - lmz 10mo ago
      This is how we get sites that block software tokens and only allow a whitelist of hardware based tokens.
      - otabdeveloper4 10mo ago
        You mean "hardware based token", because of course we only know of only one brand and specific make.
josephg 10mo ago
> 2FA is "something you have" (or ".. you are", for biometrics): it is supposed to prove that you currently physically posses the single copy of a token. The textbook example is a TOTP stored in a Yubikey. No, 2FA means authentication using 2 factors of the following 3 factors: - What you know (eg password) - What you have (eg physical token) - What you are (eg biometrics) You can "be the 2FA" without a token by combining a password (what you know) and biometrics (what you are). Eg, fingerprint reader + password, where you need both to login.
- crote 10mo ago
  Of course, but in most applications the use of a password is a given, so in day-to-day use "2FA" had come to mean "the other auth method, besides your password". Combine that with the practical problems with biometrics when trying to auth to a remote system, and in practice that second factor is more often than not "something you have". And biometrics is usually more of a three-factor system, with the device you enrolled your fingerprints on being an essential part of the equation.
- moralestapia 10mo ago
  This. GP ignores the conventions of the field.
PunchyHamster 10mo ago
misunderstanding of 2FA annoys me. Like, banking site requiring phone's 2FA (whether actual or SMS), okay, you have to know password and access to the device or at least a SIM card so 2 things need to be compromised. Computer vulnerable, no problem, phone vulerable, no problem, both need to be vulnerable to defeat it ...then someone decided to put banking on the second factor and now phone has both password and token (or access to SMS) to make a transaction, so whole system is one exploit away from defeat.
madeofpalk 10mo ago
I don't think OP claimed it adds value. > It explores the limits of time-based authentication under strict human constraints and makes no claims of cryptographic equivalence to standard TOTP. I think they're just having fun.
newpavlov 10mo ago
>The obvious next step is to do all the math in client-side code and just have the user enter the secret https://en.wikipedia.org/wiki/Password-authenticated_key_agreement https://en.wikipedia.org/wiki/Password-authenticated_key_agr...
chias 10mo ago
> this has been watered down a lot by the way-too-common practice of storing TOTP secrets in password managers I'm open to discovering I'm wrong here, but I have never understood this line of thinking. Assuming you 2fa into your password manager when you first sign in on your device, it's still 2 factors all the way down. As you sign into your password manager, the "something you have" is your 2fa device that you use to sign into your password manager (which is obviously not being filled in by your password manager). Subsequent password manager unlocks which don't prompt for your token are still 2fa because the "something you have" is your computer with which you signed into your password manager. Why is this a problem?
- theamk 10mo ago
  What if your computer, which runs your password manager, is compromised? If the malware has system access, it can often export all the passwords. Depending on level of protection and OS, this could require kernel access, root access, a regular user access or maybe just a hijacked browser extension. This leaks every single password in the vault, including any TOTP keys - so if you were storing your TOTP password here, you are now screwed, and attacker has a full access. On the other hand, if your TOTP was a separate device, your TOTP-protected accounts are fine. And even if it's just an app on your phone, you are likely still fine, as phones have much stronger isolation, and people don't usually "npm install" random stuff on them. (And that's Google Authenticator adding cloud backup functionality is such a bad idea.. If you enable it, then all your 2FAs are leaked once Google password is leaked) (You could argue that your password manager stores TOTP secrets in secure enclave and it's impossible to extract from there... but those same secrets have to be stored in your account as well, and they could be extracted from there)
  - chias 9mo ago
    Isn't this the same chicken-and-egg problem? > If you enable it, then all your 2FAs are leaked once Google password is leaked Nope, you'd also need my Google 2fa.
labcomputer 9mo ago
I tend to agree that this doesn't really add a second factor. After all, both the mTOTP secret and the password are something you know, and something you could tell someone else. However, I do think there is added value here, at least in principle: It increases the difficulty of credential stuffing attacks, which, IMHO is the main value of having a TOTP secret stored in one or more password managers. "Regular" TOTP stored in a password manager also helps with password reuse when a site is compromised because each site has a different TOTP secret. It seems implausible that a user could remember a different mTOTP secret for each site.

by crote 10mo ago

brna-2 10mo ago

Time based skew makes it a changeable second factor, additional changeable pass makes it the second factor, Also - if the first factor is a password manager or ssh key - this is the second factor. The idea of it was so neat to me, I just had to thinker with it.

ulrikrasmussen 10mo ago

In practice most TOTP implementation also do not prove that you have a device which is the sole owner of the secret. Except for proprietary app-based solutions the usual protocol is to display a QR code which just encodes the secret in plain text. As long as you never enter the secret anywhere but only do the computation is your head, this is just using your brain as the second factor. I would not call this a password since it is not used in the same way. Passwords are entered in plain text into fields that you trust, but that also means that passwords can be stolen. This proves that you are in possession of your brain.

swiftcoder 10mo ago
> Passwords are entered in plain text into fields that you trust, but that also means that passwords can be stolen The only difference here is that you are hashing the password in your head, instead of trusting the client to hash it for you before submitting it to the server. Which makes the threat model here what, exactly? Keyloggers, or login pages that use outdated/insecure methods to authenticate with the server?
- ulrikrasmussen 10mo ago
  Yes, but also plain guessing since passwords are usually chosen by the user and not generated by the server like TOTP secrets. Also phishing attacks tricking users into entering their passwords in fake login pages, and stolen password databases.
  - swiftcoder 10mo ago
    > Yes, but also plain guessing since passwords are usually chosen by the user and not generated by the server like TOTP secrets. If we were talking a >256-bit secret, I'd buy this, but in the human-calculated case I don't see how it actually helps with this, because you've substituted a ~8 character password for a 6 digit number, which is significantly less search space to brute-force. > Also phishing attacks tricking users into entering their passwords in fake login pages yes, this is more-or-less a subset of the "keylogger/insecure login page" case > and stolen password databases There's still a server-side TOTP secret database to be stolen, no? And normally that would be hard to reverse-engineer the actual secret from, but again, you've shrunk the search space down to 1,000,000 entries, which is trivial to brute force.

rcxdude 10mo ago

The single copy part would be a lot more common if it was widely supported to have multiple tokens registered to an account. And the main point (though I agree that it doesn't make it 2FA), is to not have the secret be disclosed when you prove that you have it, which is what TOTP also achieves, which makes phishing or sniffing it significantly less valuable.

crote 10mo ago
Are there any mainstream websites which only allow a single TOTP token to be enrolled? I can't remember having ever run into that issue. I do recall it occasionally being an issue with Passkeys, though. The non-disclosure is indeed neat, but the same can be achieved with a password. For example: generate public/private keypair on account creation. Encrypt private key with user password. Store both on server. On auth, client downloads encrypted priv key, decrypts it with user-entered password, then signs nonce and provides it to server as proof of knowledge of user password.
- fc417fc802 10mo ago
  You don't need to involve a private key there. Modern password authentication algorithms never reveal the bare secret (outside of initial registration ofc). For example, PAKE uses Diffie-Hellman coupled with the (salted) password hash to independently derive the same session key on both sides of the connection. AFAIK the primary technical concerns are insecure storage by the server (bad hash or salt) or keylogging of the client device. But the real issue is the human factor - ie phishing. As long as the shared secret can't be phished it solves the vast majority of real world problems. Point being, TOTP on a rooted phone handled by a FOSS password manager app whose secret store the end user retains full access to will successfully prevent the vast majority of real world attacks. You probably shouldn't use a FOSS password manager on a rooted device for your self hosted crypto wallet though.
  - crote 10mo ago
    Ah, of course! I did initially consider DH as example, but discounted it because of the need for the server to store the plaintext password - the fact that you can just hash it first completely slipped my mind. I completely agree about phishing being the main attack vector. However, I do think malware is a not-too-distant second - which makes having a single device contain both your password and TOTP secret a Really Bad Idea. Having not-perfectly-secure TOTP codes only your phone and a password manager DB only on your desktop is a pretty decent solution for that.

fxj 10mo ago

TOTP is also just password + some computation. So where is the difference? There is a lot of security theatre around TOTP with the QR code and then need of an app but you can write a 8 liner in python that does the same when you extract the password out of the QR code. import base64 import hmac import struct import time def totp(key, time_step=30, digits=6, digest='sha1'): key = base64.b32decode(key.upper() + '=' \* ((8 - len(key)) % 8)) counter = struct.pack('>Q', int(time.time() / time_step)) mac = hmac.new(key, counter, digest).digest() offset = mac[-1] & 0x0f binary = struct.unpack('>L', mac[offset:offset+4])[0] & 0x7fffffff return str(binary)[-digits:].zfill(digits) https://dev.to/yusadolat/understanding-totp-what-really-happens-when-you-generate-that-6-digit-code-1ael https://dev.to/yusadolat/understanding-totp-what-really-happ...

crote 10mo ago
You are supposed to store the password in a Secure Enclave, which you can only query for the current token value. You are also supposed to immediately destroy the QR code after importing it. As I already mentioned, the fact that people often use it wrong undermines its security, but that doesn't change the intended outcome.
- alt227 10mo ago
  IMO if it is possible to use a system wrongly which undermines its security, it is already broken.
  - lmz 10mo ago
    This is how we get sites that block software tokens and only allow a whitelist of hardware based tokens.
    - otabdeveloper4 10mo ago
      You mean "hardware based token", because of course we only know of only one brand and specific make.

josephg 10mo ago

> 2FA is "something you have" (or ".. you are", for biometrics): it is supposed to prove that you currently physically posses the single copy of a token. The textbook example is a TOTP stored in a Yubikey. No, 2FA means authentication using 2 factors of the following 3 factors: - What you know (eg password) - What you have (eg physical token) - What you are (eg biometrics) You can "be the 2FA" without a token by combining a password (what you know) and biometrics (what you are). Eg, fingerprint reader + password, where you need both to login.

crote 10mo ago
Of course, but in most applications the use of a password is a given, so in day-to-day use "2FA" had come to mean "the other auth method, besides your password". Combine that with the practical problems with biometrics when trying to auth to a remote system, and in practice that second factor is more often than not "something you have". And biometrics is usually more of a three-factor system, with the device you enrolled your fingerprints on being an essential part of the equation.
moralestapia 10mo ago
This. GP ignores the conventions of the field.

PunchyHamster 10mo ago

misunderstanding of 2FA annoys me. Like, banking site requiring phone's 2FA (whether actual or SMS), okay, you have to know password and access to the device or at least a SIM card so 2 things need to be compromised. Computer vulnerable, no problem, phone vulerable, no problem, both need to be vulnerable to defeat it ...then someone decided to put banking on the second factor and now phone has both password and token (or access to SMS) to make a transaction, so whole system is one exploit away from defeat.

madeofpalk 10mo ago

I don't think OP claimed it adds value. > It explores the limits of time-based authentication under strict human constraints and makes no claims of cryptographic equivalence to standard TOTP. I think they're just having fun.

newpavlov 10mo ago

>The obvious next step is to do all the math in client-side code and just have the user enter the secret https://en.wikipedia.org/wiki/Password-authenticated_key_agreement https://en.wikipedia.org/wiki/Password-authenticated_key_agr...

chias 10mo ago

> this has been watered down a lot by the way-too-common practice of storing TOTP secrets in password managers I'm open to discovering I'm wrong here, but I have never understood this line of thinking. Assuming you 2fa into your password manager when you first sign in on your device, it's still 2 factors all the way down. As you sign into your password manager, the "something you have" is your 2fa device that you use to sign into your password manager (which is obviously not being filled in by your password manager). Subsequent password manager unlocks which don't prompt for your token are still 2fa because the "something you have" is your computer with which you signed into your password manager. Why is this a problem?

theamk 10mo ago
What if your computer, which runs your password manager, is compromised? If the malware has system access, it can often export all the passwords. Depending on level of protection and OS, this could require kernel access, root access, a regular user access or maybe just a hijacked browser extension. This leaks every single password in the vault, including any TOTP keys - so if you were storing your TOTP password here, you are now screwed, and attacker has a full access. On the other hand, if your TOTP was a separate device, your TOTP-protected accounts are fine. And even if it's just an app on your phone, you are likely still fine, as phones have much stronger isolation, and people don't usually "npm install" random stuff on them. (And that's Google Authenticator adding cloud backup functionality is such a bad idea.. If you enable it, then all your 2FAs are leaked once Google password is leaked) (You could argue that your password manager stores TOTP secrets in secure enclave and it's impossible to extract from there... but those same secrets have to be stored in your account as well, and they could be extracted from there)
- chias 9mo ago
  Isn't this the same chicken-and-egg problem? > If you enable it, then all your 2FAs are leaked once Google password is leaked Nope, you'd also need my Google 2fa.

labcomputer 9mo ago

I tend to agree that this doesn't really add a second factor. After all, both the mTOTP secret and the password are something you know, and something you could tell someone else. However, I do think there is added value here, at least in principle: It increases the difficulty of credential stuffing attacks, which, IMHO is the main value of having a TOTP secret stored in one or more password managers. "Regular" TOTP stored in a password manager also helps with password reuse when a site is compromised because each site has a different TOTP secret. It seems implausible that a user could remember a different mTOTP secret for each site.