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

91–100 of 116 posts

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

#91

Post by TeMPOraL »

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.

On the contrary - perfect security is only possible if your system is an inert rock. Or not even then, as the users could still use the rock "wrong" by beating security maximalists over their heads with it.

Also honestly TIL that TOTP are somehow supposed to also enforce a single copy of the backing token being in existence. That's not just bad UX, that feels closer to security overreach.

People in tech, especially software and security folks, tend to miss the fact that most websites with 2FA already put a heavier security burden on their users than anything else in real life. There's generally no other situation in peoples' lives that would require you to safely store for years a document that cannot be recovered or replaced when destroyed[0]. 2FA backup codes have much stricter security standard than any government ID!

And then security people are surprised there's so much pushback on passkeys.

--

[0] - The problem really manifest when you add lack of any kind of customer support willing to or capable of resolving account access issues.

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

#92

Post by krkhan »

craftkiller wrote: post #85
gruez wrote: post #82

Earlier quoted context omitted.

>You are supposed to store the password in a Secure Enclave, That's at best a retcon, given given that the RFC was first published in 2008 >You are also supposed to immediately destroy the QR code after importing it. Most TOTP apps support backups/restores, which defeats this.

> That's at best a retcon, given given that the RFC was first published in 2008 How so? Apple didn't invent the idea of a secure enclave. Here is a photo of one such device, similar to one I was issued for work back in ~2011: https://webobjects2.cdw.com/is/image/CDW/1732119 No option to get the secret key out. All you can get out is the final TOTP codes. If anything, having an end-user-programmable "secure enclave" i…

[dead]

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

#93

Post by alphager »

ACCount37 wrote: post #83
Ferret7446 wrote: post #78

Earlier quoted context omitted.

Exactly, which is why TOTP is "weak". "Real" 2FA like FIDO on a security key makes it much harder.

TOTP is the "good enough" 2FA. If I managed to intercept a login, a password and a TOTP key from a login session, I can't use them to log in. Simply because TOTP expires too quickly. That's the attack surface TOTP covers - it makes stealing credentials slightly less trivial by making one of the credentials ephemeral.

The 30 seconds (+30-60 seconds to account for clock drift) are long enough to exploit.

TOTP is primarily a defense against password reuse (3rd party site gets popped and leaks passwords, thanks to TOTP my site isn't overrun by adversaries) and password stuffing attacks.

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

#96

Post by theamk »

chias wrote: post #90
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…

> 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, you are now screwed, and attacker has a full access. On the other hand, if your TOTP was a separate device, your TOTP-protected accounts are fine. And even if it's just an app on your phone, you are likely still fine, as phones have much stronger isolation, and people don't usually "npm install" random stuff on them.

(And that's Google Authenticator adding cloud backup functionality is such a bad idea.. If you enable it, then all your 2FAs are leaked once Google password is leaked)

(You could argue that your password manager stores TOTP secrets in secure enclave and it's impossible to extract from there... but those same secrets have to be stored in your account as well, and they could be extracted from there)

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

#97

Post by vel0city »

alphager wrote: post #93
ACCount37 wrote: post #83

Earlier quoted context omitted.

TOTP is the "good enough" 2FA. If I managed to intercept a login, a password and a TOTP key from a login session, I can't use them to log in. Simply because TOTP expires too quickly. That's the attack surface TOTP covers - it makes stealing credentials slightly less trivial by making one of the credentials ephemeral.

The 30 seconds (+30-60 seconds to account for clock drift) are long enough to exploit. TOTP is primarily a defense against password reuse (3rd party site gets popped and leaks passwords, thanks to TOTP my site isn't overrun by adversaries) and password stuffing attacks.

In every system I've worked on recent successful TOTPs have been cached as well to validate they're not used more than once.

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

#98

Post by otabdeveloper4 »

lmz wrote: post #45
alt227 wrote: post #40

Earlier quoted context omitted.

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.

You mean "hardware based token", because of course we only know of only one brand and specific make.

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

#99

Post by zzo38computer »

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.

That is what I thought too, when I read it. (I was going to mention it if I did not find someone else already did.)

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

#100

Post by crote »

ulrikrasmussen wrote: post #72
crote wrote: post #63

Earlier quoted context omitted.

Not true. There are lots of authentication schemes where the plaintext password is never communicated. This becomes rather crucial when the client doesn't know for sure yet what the identity of the other side is. See for example wifi encryption. Cloning the knowledge in someone's brain is fairly easy. You just need a wrench.

Yes, but that is not how passwords work since the protocol for proving knowledge is that you enter it into the HTML form served by the party claiming to be the verifier. If we are talking rubber-hose cryptography then a physical hardware token is just an insecure as a brain. Most people are not hacked via wrenches.

In other words: it's how passwords work on websites. Because it's usually good enough, as the only thing you are protecting is access to the server on the other side, and the pipe to that is already encrypted with TLS.

But this isn't a hard requirement. See Protonmail as a counterexample. And again, wifi authentication. I reckon debit card PINs as well.

Post reply on HN