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

51–60 of 116 posts

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

#51

Post by madeofpalk »

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

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

#52

Post by newpavlov »

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…

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

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

#53

Post by brna-2 »

MattPalmer1086 wrote: post #20
MattPalmer1086 wrote: post #12

Earlier quoted context omitted.

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.

Also @MattPalmer1086 the best solution for this I have now is to have several secret keys and rotate usage. Would be nice to have some additional security boosts.

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

#54

Post by leothetechguy »

ramon156 wrote: post #37
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.

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.

The security advantage I see in mtotp is that you never reveal the password to the system you are authenticating with, but that there is also no electronic device that can be compromised

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

#55

Post by thfuran »

i-con wrote: post #48
brna-2 wrote: post #10

Earlier quoted context omitted.

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'm not an expert, but roughly know the numbers. Usually with password-based key derivation, one would increase resource needs (processor time, memory demand) to counter brute forcing. Not an option for a human brain, I guess. So the key would have to be longer. And random or a lot longer. Over 80 random bits is generally a good idea. That's roughly 24 decimal digits (random!). I guess about 16 alphanumerical charact…

A handful of words is generally more memorizable than the same number of bits as a random alphanumeric string. You wouldn’t need a very long pass phrase for 80 bits as long as you’re using a large dictionary.

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

#56

Post by fc417fc802 »

charcircuit wrote: post #47
fc417fc802 wrote: post #27

Earlier quoted context omitted.

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…

If a factor is "something you own", it is by design that if you lose and no longer own it then you can't pass that check.

Not true. There is no requirement that the user be incapable of cloning or recreating the possession. That's an additional constraint that some parties choose to impose for various reasons (some understandable, some BS).

In the end it's all just hidden information. The question is the difficulty an attacker would face attempting to exfiltrate that information. Would he require physical access to the device? For how long? Etc.

If the threat model is a stranger on the other side of an ocean using a leaked password to log in to my bank account but I use TOTP with a password manager (or even, god forbid, SMS codes) then the attack will be thwarted. However both of those (TOTP and SMS) are vulnerable to a number of threat models that a hardware token isn't.

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

#57

Post by rcxdude »

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

I would say the majority of services I have TOTP set up for only support one token at a time. It's only the bigger, techier services that have support for multiple.

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

#58

Post by fc417fc802 »

crote wrote: post #41
eisbaw wrote: post #26

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

Biometrics are "something you are" but they are not a good substitute for either "something you have" or "something you know".

My concern with them nearly always comes down to privacy. They are far too easy to abuse for collecting and selling user data. There are probably ways around that but how much will you ever be able to trust an opaque black box that pinky promises to irreversibly and uniquely hash your biometric data? It's an issue of trust and transparency.

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

#59

Post by Jean-Papoulos »

alt227 wrote: post #40
crote wrote: post #30

Earlier quoted context omitted.

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.

I can chuck a brick at your head. Clearly the brick is broken

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

#60

Post by elderlybanana »

fxj wrote: post #24
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…

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() + '=' \*…

Yes, TOTP is a secret + computation, and generating it is trivial once you have the secret. The security difference is that the TOTP secret is separate from the user’s password and the output is short-lived. Each of the two factors address different threat models.
Post reply on HN