I see 2FA is often misunderstood by people. The basic premise with 2FA is that you combine “something you know” with “something you have”. You are already part of the 2FA — you’re the first factor: “something you know”. The second factor: “something you have” — often a personal device, or an object. This is ideally something no one else can be in possession of at the same time as you are.
MTOTP: Wouldn't it be nice if you were the 2FA device?
31–40 of 116 posts
Re: MTOTP: Wouldn't it be nice if you were the 2FA device?
#32What 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…
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 passwor…
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?
Re: MTOTP: Wouldn't it be nice if you were the 2FA device?
#33Earlier quoted context omitted.
TOTP is also just hashing a password with a time salt. The purpose is just to prove that you are in possession of the device that stores the password without actually ever entering the password anywhere where it can be leaked. In this case the device is just your brain.
> In this case the device is just your brain And that makes it a password (i.e. the primary factor, not a second factor). The whole point of a second factor is that it's not trivially cloneable (hence why, for example, SMS is a poor form of 2FA in the presence of widespread SIM cloning attacks).
Re: MTOTP: Wouldn't it be nice if you were the 2FA device?
#34What 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…
> 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 comb…
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.
Re: MTOTP: Wouldn't it be nice if you were the 2FA device?
#35What 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…
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.
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.
Re: MTOTP: Wouldn't it be nice if you were the 2FA device?
#36Earlier quoted context omitted.
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 passwor…
> 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?
Re: MTOTP: Wouldn't it be nice if you were the 2FA device?
#37This is an early experiment in human-computable TOTP. Not production crypto, but a serious attempt to reach reasonable security for plausible 2FA. Protocol revisions, criticism, and contributions are welcome.
Nonetheless I do not see what issues 2FA has that this solves. Having the electronic device is the security. Without it there is no security.
Re: MTOTP: Wouldn't it be nice if you were the 2FA device?
#38Earlier quoted context omitted.
In that case nothing based on RFC 6838 would qualify as a second factor because nothing prevents you from just remembering the TOTP secret and compute the one-time code using a piece of JS. Or even putting it in your password manager. I think it is too simple to reduce the definition of second factor to how it is stored. It is rather a question of what you need to log in. For TOTP the client has the freedom to choose…
For proper 2nd factors the secret is a hardware key that practically can not be extracted so it is impossible for someone to know it. They must obtain the piece of hardware to use the key.
Re: MTOTP: Wouldn't it be nice if you were the 2FA device?
#39What 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…
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.
Re: MTOTP: Wouldn't it be nice if you were the 2FA device?
#40Earlier quoted context omitted.
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() + '=' \*…
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.