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.
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.
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.
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.
> 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?
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.
> 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.
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.
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.
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.
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.
I guess it's a spectrum. At one extreme is the most physically resistant hardware token in existence. On the other end is a password transmitted in plaintext.
An ssh keyfile requires an attacker to break into the device but is likely fairly easy to snag with only user level access.
Bypassing a password manager that handles TOTP calculations or your ssh key or similar likely requires gaining root and even then could be fairly tricky depending on the precise configuration and implementation. That should generally be sufficient to necessitate knowledge of the master password plus device theft by an insufficiently sophisticated attacker.
Given TOTP or an ssh key managed exclusively by a hardware token it will be all but impossible for anyone to avoid device theft. Still, even TPMs have occasionally had zero day vulnerabilities exposed.
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.
This 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.
or we could use asymmetric biometric fingerprints. Turns out features can be extracted into public and private sets, and both are required for a match. I hold a patent on it btw
I originally included it as a structural integrity digit, with the option for early rejection on the server side. That early exit check is not implemented in the current PAM module yet.
This is an early POC, and sanity checks like this are exactly the kind of feedback I’m looking for.
An interesting idea but in theory just three correct pass codes and some brute force will reveal the secret key so you'd have to be very careful about only inputting the pass code to sites that you trust well.
It's definitely computable on a piece of paper and reasonably secure against replay attacks.
Thinking about it, there are only 10 billion different keys and somewhat fewer sboxes.
So given a single pass code and the login time, you can just compute all possible pass codes. Since more than one key could produce the same pass code, you would need 2 or 3 to narrow it down.
In fact, you don't even need to know the login time really, even just knowing roughly when would only increase the space to search by a bit.
Yep, I am aware, 2 or 3 OTP's and timestamps plus some brute forcing using the source-code. Server-side brute force by input should or could be implausible.
But that is why I am signaling here that I would love a genius or a playful expert/enthusiast contributing a bit or two to it - or becoming a co-author.
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.
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).
No, the defining characteristic of a password is also how it is used: it is communicated in the clear to the verifier, thus revealing it to eavesdroppers. It is highly non-trivial to clone the knowledge in someone's brain if they never openly communicate the mTOTP secret but only do the computations in their head.
The idea is interesting, but I don't think this qualifies as a second factor, as it can be reduced to a factor you have to remember, so equivalent to a password. The second factor should be derived either from something you own, or something that can be obtained from biometry.
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 any of (not exhaustive):
1. Remember password, put TOTP in an app on smartphone => Client has to remember password and be in possession of smartphone.
2. Put password and TOTP in password manager => Client has to remember the master password to the password manager and be in possession of the device on which it runs. Technically, you have to be in possession of just the encrypted bits making up the password database, but it is still a second factor separate from the master password.
> I think it is too simple to reduce the definition of second factor to how it is stored.
I think the defining characteristic is how it is used. I can use a password like a second factor, and I can use a TOTP code like a password. The service calls it a password or a second factor because that was the intention of the designer. But I can thwart those intentions if I so choose.
Recall the macabre observation that for some third factor implementations the "something you are" can quickly be turned into "something your attacker has".
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.
Yes, that is certainly a more secure second factor since there are fewer ways for an attacker to steal it, but I don't think that should be a necessary condition for it to be called a second factor at all.
Can't say I agree with this take. Sure, something hardware bound is more secure under certain threat models. For others it's largely irrelevant. There are also drawbacks, such as not being able to back it up. That might or might not matter. "Just" get a second hardware token, register that as well, and store it somewhere safe won't always be a realistic (or perhaps desirable) option for everyone in every scenario. It certainly reduces your flexibility.
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.
Except that for 99% of my passwords, I am 100% sure I do not, and never will, know them, they are 60-100+ bytes of random data, only known by my passwordmanager.
The only thing I know, is the passphrase for my passwordmanager. TOTP codes are also stored in there, but I see it more as a replay-protection for captured passwords, though this is also really a non-issue in this time of almost no plaintext protocols.
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.
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.
https://dev.to/yusadolat/understanding-totp-what-really-happ...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.
IMO if it is possible to use a system wrongly which undermines its security, it is already broken.
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.
> 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?
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.
> 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.
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.
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.
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.
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.
I guess it's a spectrum. At one extreme is the most physically resistant hardware token in existence. On the other end is a password transmitted in plaintext.
An ssh keyfile requires an attacker to break into the device but is likely fairly easy to snag with only user level access.
Bypassing a password manager that handles TOTP calculations or your ssh key or similar likely requires gaining root and even then could be fairly tricky depending on the precise configuration and implementation. That should generally be sufficient to necessitate knowledge of the master password plus device theft by an insufficiently sophisticated attacker.
Given TOTP or an ssh key managed exclusively by a hardware token it will be all but impossible for anyone to avoid device theft. Still, even TPMs have occasionally had zero day vulnerabilities exposed.
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.
This 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.
I don't really get what tone you're doing for. Is this "a serious attempt", or is this "something that does not guarantee any cryptographic security"?
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.
or we could use asymmetric biometric fingerprints. Turns out features can be extracted into public and private sets, and both are required for a match. I hold a patent on it btw
I remain very skeptical of fingerprints.
They are both too mutable (cuts and burns will alter them) and not mutable enough (you can't re-roll your fingerprints after a leak).
On top of that, you are also literally leaving them on everything you touch, making it trivial for anyone in your physical presence to steal them.
They are probably pretty decent for police use, but I don't believe they are a good replacement for current tech when it comes to remote auth.
What is the purpose of the 6th digit?
It doesnt add any security, as it is trivially computable from the other digits already computed.
It appears to be a checksum, but I can't see why one would be needed.
I originally included it as a structural integrity digit, with the option for early rejection on the server side. That early exit check is not implemented in the current PAM module yet.
This is an early POC, and sanity checks like this are exactly the kind of feedback I’m looking for.
It probably isn't for security, it is more likely a quick check that the code that you memorized makes sense.
An interesting idea but in theory just three correct pass codes and some brute force will reveal the secret key so you'd have to be very careful about only inputting the pass code to sites that you trust well.
It's definitely computable on a piece of paper and reasonably secure against replay attacks.
I was wondering about the overall security. How did you determine that 3 pass codes and brute force will reveal the secret key?
Thinking about it, there are only 10 billion different keys and somewhat fewer sboxes.
So given a single pass code and the login time, you can just compute all possible pass codes. Since more than one key could produce the same pass code, you would need 2 or 3 to narrow it down.
In fact, you don't even need to know the login time really, even just knowing roughly when would only increase the space to search by a bit.
Yep, I am aware, 2 or 3 OTP's and timestamps plus some brute forcing using the source-code. Server-side brute force by input should or could be implausible. But that is why I am signaling here that I would love a genius or a playful expert/enthusiast contributing a bit or two to it - or becoming a co-author.
I don't think people plan what time to log into things.
Yep, they did not need to when the calculation was done in real time on a mobile phone. :D
Isn't this just manually hashing a password with a timed-salt? I don't see how this relates to TOTP
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).
No, the defining characteristic of a password is also how it is used: it is communicated in the clear to the verifier, thus revealing it to eavesdroppers. It is highly non-trivial to clone the knowledge in someone's brain if they never openly communicate the mTOTP secret but only do the computations in their head.
The idea is interesting, but I don't think this qualifies as a second factor, as it can be reduced to a factor you have to remember, so equivalent to a password. The second factor should be derived either from something you own, or something that can be obtained from biometry.
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 any of (not exhaustive):
1. Remember password, put TOTP in an app on smartphone => Client has to remember password and be in possession of smartphone.
2. Put password and TOTP in password manager => Client has to remember the master password to the password manager and be in possession of the device on which it runs. Technically, you have to be in possession of just the encrypted bits making up the password database, but it is still a second factor separate from the master password.
> I think it is too simple to reduce the definition of second factor to how it is stored.
I think the defining characteristic is how it is used. I can use a password like a second factor, and I can use a TOTP code like a password. The service calls it a password or a second factor because that was the intention of the designer. But I can thwart those intentions if I so choose.
Recall the macabre observation that for some third factor implementations the "something you are" can quickly be turned into "something your attacker has".
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.
Yes, that is certainly a more secure second factor since there are fewer ways for an attacker to steal it, but I don't think that should be a necessary condition for it to be called a second factor at all.
Can't say I agree with this take. Sure, something hardware bound is more secure under certain threat models. For others it's largely irrelevant. There are also drawbacks, such as not being able to back it up. That might or might not matter. "Just" get a second hardware token, register that as well, and store it somewhere safe won't always be a realistic (or perhaps desirable) option for everyone in every scenario. It certainly reduces your flexibility.
I put them in my password manager
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.
Except that for 99% of my passwords, I am 100% sure I do not, and never will, know them, they are 60-100+ bytes of random data, only known by my passwordmanager. The only thing I know, is the passphrase for my passwordmanager. TOTP codes are also stored in there, but I see it more as a replay-protection for captured passwords, though this is also really a non-issue in this time of almost no plaintext protocols.
Really nice idea