Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MTOTP: Wouldn't it be nice if you were the 2FA device?

github.com

Post reply on HN
Print view View original

111–116 of 116 posts

Re: MTOTP: Wouldn't it be nice if you were the 2FA device?

#111

Post by shaftway »

brna-2 wrote: post #2

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.

Re: MTOTP: Wouldn't it be nice if you were the 2FA device?

#113

Post by MattPalmer1086 »

brna-2 wrote: post #21
MattPalmer1086 wrote: post #13

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.

Probably not needed.

The computation of the code is not computationally expensive (human computation is a requirement) so no real impact on server having to perform the full computation.

I guess if implemented client side it might provide a sanity check for the user before submitting, but it's more work for the human and they are almost as likely to get the checksum calculation wrong as any other part of it.

So I would probably remove it.

Re: MTOTP: Wouldn't it be nice if you were the 2FA device?

#114

Post by chias »

theamk wrote: post #96
chias wrote: post #90

Earlier quoted context omitted.

> 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…

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,…

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.

Re: MTOTP: Wouldn't it be nice if you were the 2FA device?

#115

Post by labcomputer »

crote wrote: post #5

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…

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.

Re: MTOTP: Wouldn't it be nice if you were the 2FA device?

#116

Post by labcomputer »

crote wrote: post #35
rcxdude wrote: post #15

Earlier quoted context omitted.

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.

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,…

> Are there any mainstream websites which only allow a single TOTP token to be enrolled?

I have definitely run into this a more often than not. It seems like only the largest and/or most security-focused tech companies allow multiple TOTP secrets. At this point I have made it a habit to ensure the TOTP secret has been stored in more than one place before dismissing the QR code.

Some even restrict you to one of: one hardware security token, one PassKey or one TOTP token.

> 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.

That's basically how PassKeys work, except that the security token's private key is used to encrypt/decrypt the login private key and sign the nonce.

Post reply on HN