Live data from Hacker News

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

github.com

41–50 of 116 posts

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

#41
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 for current tech when it comes to remote auth.

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

#42
post #15
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 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.

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

#43

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.

Yep known issue, was hoping someone could spice the protocol up without making it mentally to heavy, hn is full of smart playful people.

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

#44

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.

[deleted]

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

#45
post #40
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.

This is how we get sites that block software tokens and only allow a whitelist of hardware based tokens.

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

#46

Earlier quoted context omitted.

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.

I'm specifically talking about the "something you own" second factor. There are other factors which could be used as a second factor.

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

#47

Earlier quoted context omitted.

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.

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.

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

#48
post #10
post #4

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.

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 characters would do to, again random. Or a very long passphrase.

So either remember long, random strings or doing a lot more math. I think it's doable but really not convenient.

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

#49
post #40
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.

There is no system which cannot be used wrongly in a way which undermines it’s security.

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

#50
post #35
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,…

You don't need to involve a private key there. Modern password authentication algorithms never reveal the bare secret (outside of initial registration ofc). For example, PAKE uses Diffie-Hellman coupled with the (salted) password hash to independently derive the same session key on both sides of the connection.

AFAIK the primary technical concerns are insecure storage by the server (bad hash or salt) or keylogging of the client device. But the real issue is the human factor - ie phishing. As long as the shared secret can't be phished it solves the vast majority of real world problems.

Point being, TOTP on a rooted phone handled by a FOSS password manager app whose secret store the end user retains full access to will successfully prevent the vast majority of real world attacks. You probably shouldn't use a FOSS password manager on a rooted device for your self hosted crypto wallet though.

Post reply on HN