Hacker News Reader

Comment by dwedge | Hacker News Reader

I was reading your other blog post about storing them in bitwarden I have to disagree with this point:

> Unless you were forced to by some organisational policy, there’s no point setting up 2FA only to reduce the effective security to 1FA because of convenience features.

2FA both stored in your password manager is less secure than storing than separately, but it still offers security compared to a single factor. The attack methods you mentioned (RAT, keylogger) require your device to be compromised, and if your device is not compromised 2fa will help you.

To slip into opinion mode, I consider my password manager being compromised to be mostly total compromise anyway.

Also I really like the style and font of your blog.

View on HN

> To slip into opinion mode, I consider my password manager being compromised to be mostly total compromise anyway.

But how is that no the entire point? If your 2FA is a proper device, like a Yubikey, the attack surface is tinier than tiny and the device ensures that your secret never leaves the device.

We did see cases of passwords managers getting compromised. We haven't seen yet a secret being extracted from a Yubikey.

So where you say you consider that your software (password manager) getting compromised is total compromise, we're saying: "as long as the HSM on a Yubikey does its job, we have actual 2FA and there cannot be a total compromise".

You're right, I should have been more clear in that I meant a local compromise of the machine running the password manager client, not the server running the password manager itself. If my sessions and all of my data can be intercepted, the yubikey 2fa seems like it's only saving me from a token "nobody can login remotely to this one service" which at that point seems pretty moot

Yubikey offers a false sense of security in that regard, unfortunately, because if your device is thoroughly 0wned and you don't know it, the attacker "just" has to wait for the victim to do something that would trigger the yubikey, and then swap in their forged request instead. Eg if the victim uses the yubikey to log into bank1 and to crypto wallet, but bank1 accounts have no money, instead of waiting for the customer to log into their crypto wallet with the yubikey, the attack software waits for the victim to log into bank1, but swaps in a request to the crypto wallet instead.

Not sure I understand your point. Under WebAuthn / FIDO2 you can't impersonate a RP

Could you explain better?

If the user's computer is pwned, you can wait for the user to log in to their bank account, then blank the screen while you send yourself all their money.

WebAuthn assumes the browser is secure. If the browser is compromised, then impersonation becomes possible, so the user, thinking they're authorizing adding a new ssh key on GitHub.com by touching their yubikey, gets their money stolen by the hacked web browser because it has an invisible hidden window with bank.com waiting for yubikey authentication.

Reply on news.ycombinator.com