Hacker News Reader

Actually interestingly point number one probably holds true, since very few GUI password managers actually document their threat model at all and actually evaluate their design decisions accordingly.

E.g. typical browser extensions if used with no additional confirmation allow easy local exfiltration of passwords. Particularly if actual user input on each request is needed TOTP would provide additional benefits (similar to your fido key button press). Password managers often compromise the effort of a single click for much less security of autofill.

Depending on your perspective, a password manager with autofill could actually be more secure.

If password managers autofill or suggest accounts based on matching domain, then you're insulated from phishing attacks due to not validating the domain. If you always copy-paste your credentials, you are relying on your own perfect vigilance in checking the domain when pasting the password for the intended site into the actual site. By using autofill or autosuggest, the computer is checking the domain for you and the failure to autofill or find related credentials can indicate a phishing attempt by disrupting your expectations.

I think that auto-suggest, meaning the password manager only suggests a password, but you need to actively click on the suggestion in order for the password to be entered, would satisfy both requirements: mitigate phishing and exfiltration. This is the default for 1password.

This is also the case for bitwarden. I think it's only browser built in autofill that does it proactively

Bitwarden has an auto fill option, though it was off by default last I checked. LastPass too has auto fill yet mitigated by requiring a click to populate the match.

> LastPass too has auto fill yet mitigated by requiring a click to populate the match.

Actually, if you login/authenticate to LastPass, it will automatically autofill the forms within all of your open tabs. It's quite irritating--I haven't figured out a way to disable it.

The problem is not on the browser interface side but on the interface of the secure password store: here you would need to give your ok (like with a hw key). At least in my password manager it seems possible to impersonate the browser after extracting the shared communication token and then query the whole database once it is unlocked from a random client.

What's the threat model you are considering?

Well considering that the local password managers make a great fuzz about memory randomisation and protection of localhost communication, I would consider a trojan running under user privileges a threat myself that a password manager should address. Otherwise it seems little better than a plaintext password file saved on an encrypted hard drive. However, my point is that mostly I just want to know what the software is good for, ie. protecting me against.

I remember KeePass had a feature where the autofill was supposed to be safe against key loggers (as opposed to typing out the password yourself)

TOTPs are also a defense against phishing leading to persistence. You can't phish someone and then lock them out of their account by changing their login details.

Other second factors (like ubi-key) are better against phishing because they are cryptographically linked to the domain. This does require some form of challenge-response.

I'm not sure this is a meaningful threat model. "Well, the adversary can authenticate as me but they'll have to reauthenticate to change my credentials so I'm a little bit safe" is a major stretch. You've already been pwned at that point and not a lot of services force a 2FA step on actions post-login.

Most services I have used actually did require 2fa on authentication relevant changes post login. That's why I mentioned this slight protection.

I'll grant the threat model is of marginal relevance.

I disagree on phishing protection. In the best case the phisher has 30 seconds to login, and then has enough time to change the login details.

The point is that changing login details often requires the 2FA. And I presume that a TOTP cannot be used twice.

There's also the fact that it helps to somewhat mitigate phishing, in that they'll only offer to autofill the code if the website domain matches the one on file, like they do for the password.

I am not an expert, but "Threat models in which a separate setup would have a benefit include only breaches of your password database itself." doesnt this mean that there is a big difference if the attack vector is by a keylogger? (Which can sniff the Database pw). Are keyloggers not a common thing for threats (I dont know)?

Not sure how common it is but if the endpoint is compromised to the point of having a keylogger installed then it's basically already game over.

Ah, I think I get the point, but is it really like this? The attacker would have to do everything through the endpoint, isnt this cumbersome for the attacker?

It would be, but if they had a keylogger installed then the endpoint is completely owned, in which case they could just exfiltrate the password database from memory. Or they can just pilfer authentication/session tokens directly once you logged in. More generally, making things more cumbersome (in the sense of requiring more steps) doesn't really provide any meaningful security since it can generally be automated anyway.

If the key logger is in a peripheral then the TOTP/password manager can still protect from replay attacks. If the key logger is on the computer then it has access to the password vault and the vault secret.

If your password store is owned then the attacker has both your credentials and the second factor. So in that way, the password manager has sacrificed a security fail-safe.

If your password store is owned, you’re fucked. Period.

2FA will offer little failsafe in such a scenario.

Not quite, that's why 2FA is supposed to be a second factor, not just extra data in the same place.

If your second factor is on separate hardware then even total compromise of the first piece of hardware (the laptop containing the password database) is not sufficient.

The separate hardware could be many things. One is something like yubikey etc. Or a separate computer with the TOTP secrets, etc.

Why so? If you don't have second factors in your PW store, then any service which actually implements MFA properly shouldn't let anyone have access to anything.

> If your password store is owned, you’re fucked. Period.

Factually incorrect. In that scenario, REAL 2FA (the kind not stored in the password store) is the only thing keeping bad guys out until you change passwords.