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.
The algorithm for the checksum (the sixth digit) is subject to one of the most common human errors, swapping adjacent digits. The UPC checksum algorithm handles this without significantly more complexity. They have you multiply all of the numbers in odd positions by 3 and then add up all numbers. The last digit is chosen to make the sum a multiple of 10.
To use your example: 51076, you'd do `5*3 + 1 + 0*3 + 7 + 6*3 = 15 + 1 + 0 + 7 + 18 = 41`. The sixth digit would be 9 ((10 - (41 mod 10)) mod 10). If you were to transpose any two adjacent numbers the checksum would be off. 3 is chosen because it's the smallest number that is co-prime with 10.
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.
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.
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.
> 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.
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.
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.
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
Yes! I've been thinking about a similar idea in October, using a "keyed hash" of the challenge computed with playing cards. I have no idea how secure this is, but the concept itself is exciting: the mental labor might function as a useful anti-coercion/fishing tool.
Interesting idea but I don't think my users will grok this :)
The worst thing about it is that people will go like "uuuh naaaah" and will just grab a random app off the play store and put their code in it. Now you are leaking secrets to whatever random app they use.
If you can be tied to a chair and beaten with a rubber hose until you produce the token, it's just a password, albeit one that rotates.
TOTP works because you have to possess the secure device at the time you're authenticating. If you don't have the device, then no amount of time with the rubber hose can make you cough up the required token.
So, in my head, once I heard the idea, I started thinking of something WAY different, and maybe its worth considering. I was thinking something like a combination "security question," "captcha" and "secondary identifier" (whatever the thing that google et al do when they tell you to match the picture on your phone to complete the login)
I don't know, something like "name the fruits that correspond to your first school colors" or similar
I've been pondering about something like this for a while, nice to see someone who didn't give up after seeing how demanding actual crypto is, like I did.
I now wonder if it's possible to store a random value in one's head without it being eavesdroppable. Humans don't really do random, but it's essential for auth.
You’ve never had a concussion, gone under anesthesia, or gotten older? Memory based passwords are not durable; I personally forgot my Google account password after a surgery.
Only if I'm not useful for 2FA when dead (taking away some incentive from killing me to get to the 2FA) and the functionality isn't tied to some part of my body that can be severed by bad actors (taking away the incentive to mutilate me to get to the 2FA).
25 comments
[ 5.3 ms ] story [ 99.0 ms ] threadTo use your example: 51076, you'd do `5*3 + 1 + 0*3 + 7 + 6*3 = 15 + 1 + 0 + 7 + 18 = 41`. The sixth digit would be 9 ((10 - (41 mod 10)) mod 10). If you were to transpose any two adjacent numbers the checksum would be off. 3 is chosen because it's the smallest number that is co-prime with 10.
It's definitely computable on a piece of paper and reasonably secure against replay attacks.
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.
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?
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.
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.
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.
The worst thing about it is that people will go like "uuuh naaaah" and will just grab a random app off the play store and put their code in it. Now you are leaking secrets to whatever random app they use.
TOTP works because you have to possess the secure device at the time you're authenticating. If you don't have the device, then no amount of time with the rubber hose can make you cough up the required token.
I don't know, something like "name the fruits that correspond to your first school colors" or similar
I now wonder if it's possible to store a random value in one's head without it being eavesdroppable. Humans don't really do random, but it's essential for auth.