Hacker News Reader

Comment by razemio | Hacker News Reader

How would you fix this problem with 2fa? I can't imagine how this would work technically. Maybe I am missing something.

You could ask user to present second factor (secure one, Webauthn) for every password they access. That would be a notable obstacle for me as an attacker, but I can't imagine any organization implementing this for real (maybe apart from military/spooks and their contractors). All of the IAM solutions I know of cache their creds and password manager usually is expected to work offline as well, so I don't think you can avoid having recoverable (in the CS meaning of the word) database locally.

It doesn't need to be every password, just require 2FA to unlock the vault in the first place. Downloading the vault shouldn't strip one factor, but it seems like that is the implementation.

I'm not aware of any encryption algos that can encrypt data using a rotating key such as a TOTP code. The vault file is encrypted using the master password, if you encrypted it with the TOTP code you wouldn't be able to decrypt it 30s later, and if you have logic to parse the 2FA I can just replace your logic with return true;

Wouldn't this be an implementation detail of the password manager? Either way, I hear you that this is asking for new functionality. Still, I don't think most people think that a factor disappears depending on the caching policy of the vault on your machine. It's quite a footgun.

No, since the cached data has nothing todo with the password manager. The cached data is just an encrypted file. Sure the password manager could ask for the otp but the cache file was attacked directly. That is why I was wondering if I was missing something. To my knowledge it isn't possible to protect a file with a rotating key.

> To my knowledge it isn't possible to protect a file with a rotating key.

This is my point, it is an implementation detail of the password manager to integrate OTP or another second with decryption of the vault. Any password manager can implement this.

From the perspective of the user, you are stripping a factor for some arbitrary period of time. It's a broken implementation.

That is not correct. You can not have offline caching and otp enabled at the same time. That is why things like yubikey exist. If your are not using another 2fa method besides otp it's either the security risk or entering otp each time you access the vault. Obviously the later is not feasible.

> You can not have offline caching and otp enabled at the same time.

I'm not sure why you are having such a hard time understanding this is an implementation detail of the password manager that can change at any time. You are treating this like it cannot be implemented differently. It absolutely can.

If you have the master password and the encrypted vault then you are in. The 2FA portion is for access to the encrypted vault.

Require the second factor for decrypting the vault. It seems the second factor is "removed" as soon as you cache the vault on your machine.

Okay, but the attacker has RCE on the system doing the decryption, so they can scrape the encryption keys or the vault data out of memory. This appears to be a APT, probably a State-level actor. Once the production work machine was compromised, it's all over.

I get what you're saying, but the implementation of 2FA is still broken. If we don't fix that, we can't fix what comes next either.

I'm not aware of any 2FA that could be successfully integrated into a symmetric-key encryption algorithm. How do we fix 2FA without making the entire password vault system dependent on network access to a central LP server that is not compromised?

Good job moving the goal post.

Reply on news.ycombinator.com