[Aachen]

If you use a password manager, or another mechanism that makes each password unique and unguessable, the password and the "2FA" seed token are both the same type of secret string, and both are stored on the same disk. There is no added benefit to 2FA if you store the 2FA secret next to the password when both are generated securely

But I'm not saying you should care about this. Everyone can make their own risk assessment, especially if you know about common attacks like the data breaches that you mention

[tremon]

the password and the "2FA" seed token are both the same type of secret string

This is a category error. The 2FA seed token may be a string of bytes just like the password, but the seed is never communicated outside your device. That makes them different types of secrets: a capture of the transmitted login codes will not compromise the 2FA seed. Even if you auto-generate the password in the same way, it's the actual valuable secret that needs to leave your device -- by design.

I don't know if a website database breach compromises both keys. Is the 2FA seed a pre-shared key, or is the algorithm asymmetric? I seriously hope it's the latter, but I don't know for sure.

[8cvor6j844qw_d6]

Symmetric as another poster mentioned. With some margin for connection delays (e.g., server checks 3 codes (1 forward and 1 backward) for a total of 90 seconds) [1].

I'll be interested in a asymmetric variant although I'll probably use a popular library and call it a day if I have to get involved in 2FA.

[1]: https://auth0.com/blog/the-working-principles-of-2fa-2-facto...

[bkettle]

Do we have the crypto to build an asymmetric variant? The way that I’d immediately think to do it is have the authenticator create a signature over the current time (chunked into 30-second windows) and the service verify that signature, but obviously those signature texts are way too long to manually enter as a one-time code. (Symmetric) TOTP solves this length problem by just truncating the output of a hash function, which both the authenticator and the service can produce because they have a shared secret. But in the signature case the service would need the entire signature to validate it; any truncation would make it useless.

It’s been a while since I did any crypto. But it feels like the shortness of the one-time-code probably makes it impossible to do asymmetrically. If this is indeed the case there is probably an elegant proof or some better way of thinking about why it’s impossible. I would be interested in reading that.

[justincormack]

It is symmetric.

[_Algernon_]

Even if pw and 2fa secret are stored together you get better protection against phishing because you never enter the full 2fa secret into a website.

[Aachen]

Thanks for providing a concrete example where this is indeed the case! You're right, and I'm aware of this, but the scenario is quite constrained. This matters when:

1. The attacker either captures the OTPs on the real website, or on a phishing page. They do not have access to either the website's store of 2FA tokens, nor your password vault.

and

2a. Having you enter one or two OTPs on the login page is not enough. The phishing page can claim "wrong OTP, you can try again in 30 seconds" to get at least two codes. The attacker can open a login session and go to down immediately when you enter it, but if there is a protocol where there's a delay of e.g. 24 hours, they would need to phish you again after 24 hours and that's unusual for them to bother with (beyond opportunistically) as far as I know

or

2b. The attack isn't automated and the attacker is also not laying in wait for someone to fall for the phishing (like when having sent 10 phishing emails and waiting for one employee to bite such that they can get into an organisation). In that case, the OTP almost certainly has expired and can't be used anymore

While #1 is common, #2 is rare as far as I'm aware. Once you're into an account, you usually can navigate to e.g. a transaction page within a few seconds and then enter the same OTP¹ again (because the time window hasn't expired yet) or ask the user for a new one a few seconds later as described

A great protection against this would be a device that displays what it is that you're authorising, such as these old bank card readers that show on a little screen like "login" or "transaction of 1337€ to NL00RABO0123456789", but these go well beyond the standard 2FA seeds that you can store in a vault

Either way, you're right, there is this benefit of having 2FA even if you store them together. If this is within one's threat model, but theft of your vault is not as big a concern, it's a valid solution

¹Yes, OTP can never be the "same" by definition. But this works in 9 out of 10 customer sites that we see (security consultancy firm; thoughts are my own yada yada)

[smw]

Better idea, use something that is able to authenticate the server and disallows fishing, like yubikeys or passkeys! Much less challenging to secure than showing something on the screen.

[AstralStorm]

It also provides enhanced security against session hijacking attacks.

Most sites require 2FA for changing the password, but do not require the password for changing itself.

[freehorse]

If the threat model includes info-stealers, then having the TOTPs on the same device as the passwords is a risk.

If the threat model does not include info-stealers (and instead includes only phishing and in general getting passwords/codes intercepted, getting a website with bad security compromised etc) then having the TOTPs in the same device does not really increase risk.

Imo in the first case, one should probably not have the passwords on the phone either. Use a phone for the OTPs and computer for the passwords for example. But that is very impractical and carries increased risk of (temporarily) not being able to access stuff in certain situations. It could be a good thing depending on what one wants to guard themselves against. If your goal is to have better security than most people, using a good password manager that is not a browser and 2FAs is as many services as possible already carries you very far. If you due to work etc you have increased risk of being targeted, prob more is needed.

[Aachen]

> [...] then having the TOTPs in the same device does not really increase risk.

... and having TOTPs at all does not decrease any risk, either. There's no benefit to the situation where you store 2 good secrets in 1 place as compared to storing 1 good secret in 1 place.

[jorvi]

> There is no added benefit to 2FA if you store the 2FA secret next to the password when both are generated securely

Over this entire thread you keep repeating this, and you're so confidently wrong.

If a hacker (or shoulder peeper) gets my password to a site without a TOTP, they can login. 1FA. If I also use a TOTP adjacently, the hacker can't login and the shoulder peeper has a window of 30 seconds.

Its 2FA. Storing critical TOTPs in your password manager is bad practice and thus bad 2FA, but its still 2FA.

[littlecosmic]

yes, fair points. Thanks for clarifying.