5 ms·
These are the main threat models to be aware of: 1. Credential phishing. Where you store your TOTP secret doesn't matter. 2. OAuth phishing. Where you store y
by FreakLegion 2y ago
These are the main threat models to be aware of:
1. Credential phishing. Where you store your TOTP secret doesn't matter.
2. OAuth phishing. Where you store your TOTP secret doesn't matter. (This also runs right through FIDO and has been growing in popularity for about a decade now: https://www.trendmicro.com/en_us/research/17/d/pawn-storm-abuses-open-authentication-advanced-social-engineering-attacks.html https://www.trendmicro.com/en_us/research/17/d/pawn-storm-ab...)
3. Data breaches. Where you store your TOTP secret doesn't matter unless your password manager backs up online, that's what gets breached, and the data isn't properly encrypted. Which has happened.
4. Malware. Where you store your TOTP secret matters. This is why U2F and FIDO2 have a user presence test, but the real-world value here is overstated. Malware can always just steal your tokens.
5. Physical access. Where you store your TOTP secret matters. If you care about security though you'll have other measures in place to keep someone with physical access out, which is enough against basically anyone except governments.
Summary: A "true" second factor doesn't really matter. What matters is deciding which scenarios you care about and making sure you have security you'll actually use given those constraints.
- todotask 2y agoInteresting, how about in the Passkeys scenario where you use biometrics?
- kevincox 2y agoIt helps but isn't perfect. The attacker can't just pick up the secret. With a passkey they would need to trick you into touching it to authenticate them. Probably by timing it when you think you are about to do a regular authentication.
- FreakLegion 2y agoPasskeys are the software version ('platform authenticator') of hardware keys ('roaming authenticator'), so no touching. Biometrics in this case are an attempt in software at something like the user presence test hardware has, but this is an OS-level guard, so the guarantees are much weaker. (Of course you can also have a biometric lock on a hardware key, which would be an improvement under the physical access threat model.)
- nucleardog 2y agoI’d add another risk here because I think it’s the main one the TOTP actually ends up protecting against in this case: Credential Stuffing. Since the TOTP secret is generated by the service and not the user, it prevents credential stuffing. It can’t be reused between sites. If you’re still reusing the same password on every site this is a huge increase in security given how many services are breached. … but using a password manager and a unique password for each service already does that. So storing your TOTP secrets alongside your password in your password manager is a _very_ marginal benefit. Prevents a replay of the login if it got captured in the clear and… not much else I can think of. Where-as a “true” 2FA adds protection against malware, data breaches, physical access, and other risks. That seems like a pretty big benefit for minimal work. I think for most people using TOTP to avoid the “this shady download/keylogger controls my entire life now” scenario is a pretty clear win on effort versus risk. So I mostly agree with what you wrote here except the summary. I’d say everyone should be using “true” TOTP where they can, and if you’re going to store them alongside your password they’re little more than security theatre so don’t bother.
- the_snooze 2y agoFor the most part, 2FA is just a hack to mitigate the fact that passwords are a weak form of authentication: people reuse passwords, and websites leak them. They're better than nothing, but outside of enterprise contexts (e.g., enterprise-managed CAC cards and other hardware tokens), I think expecting 2FA to defeat malware, physical access, etc. is too much.
- nucleardog 2y ago> For the most part, 2FA is just a hack to mitigate the fact that passwords are a weak form of authentication: people reuse passwords, and websites leak them. Yep, and "using a password manager with a randomly generated password for each site" already mitigates that just as well. Barring a user using 1Password and still reusing the same password on every site (why are you using 1Password then?) the only use-case I can think of for storing TOTP tokens alongside your password in 1Password is "the service requires me to use TOTP and I don't care about security". That said, full disclosure, I've kinda got a bone to pick here because I was a long time 1Password user that was forced to switch off when 1Password removed the ability to have multiple vaults because, as they have said on their support forums, "It's called 1Password and our users only want one password." which was a... mind-boggling response from a company that should be focused on security. And this blog post really doesn't instill much more confidence than that response did. These days I have my passwords in a KeePassX database. I have my TOTP secrets stored in two places--on my phone in an authenticator app where they're on a very secure platform and practically unrecoverable, and in an entirely separate KeePassX database that has nothing in common with my password database. The only time the KeePassX TOTP database is opened is when I set up a new service and want to add my TOTP secret. It's only there to "break glass in case of emergency" and allow me to recover access if my phone were to become unavailable. It's the right balance of risk _for me_, and in most practical sense two _factor_ authentication.
- TacticalCoder 2y ago> ... but the real-world value here is overstated. Malware can always just steal your tokens. Stealing a TOTP secret means being able to generate all the tokens. Which allows, for example, to take over an user account and lock the legitimate user out of his account. MITMing a single U2F/FIDO2 allows you to... log in? From one of the system uses to access his account (the one that's compromised). I've got sites where the FIDO2 to log in and the one to change any security setting require two different security keys. And even when it only requires one security key, the procedure to take over an account requires several tap on the physical security key. A savvy user won't be tricked into tapping his security key for no reason. Let's take, say, a brokerage account. There's a security key for withdrawals. Without that security key an attacker would be MITMing me by stealing one token could... Consult, what, see my balance and trade for me!? But he still wouldn't be able to steal a cent (and my account ain't big enough to move the market). The real-world value of an HSM sitting on a device with a tiny attack surface has a lot of value. The very reason they exist being that compromised computers are a thing. Compromised Yubikeys are not.
- FreakLegion 2y ago> MITMing a single U2F/FIDO2 allows you to... log in? You mean token theft? Most sites let you add factors without step-up auth once you're logged in [1]. That's what attackers prefer to do, vs. locking users out, which just gives away the game. To be clear, end-running around hardware keys with stolen tokens isn't hypothetical. See for example the fallout from the last Okta breach at Cloudflare: https://blog.cloudflare.com/thanksgiving-2023-security-incident https://blog.cloudflare.com/thanksgiving-2023-security-incid.... I make my team use YubiKeys, but there's no upside to being naive about what they are and aren't good for. Anyway the kinds of sites you're describing are vanishingly few. What people mostly have to deal with are sites like Fidelity's. If you want something other than SMS or push notifications, you have to call Fidelity on the phone, and then all you get is Symantec's bloated wrapper around TOTP. 1. It's even the default in some major identity providers, like Microsoft's (https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-policy-registration https://learn.microsoft.com/en-us/entra/identity/conditional...). Okta is better, but then their default session length is forever, so moot point.