Keylogger Resistance

I would like to see work to provide keylogger resistance. I think keyloggers are ultimately the weakest link in an encrypted password manager. You can have perfect encryption, you can never store decryption keys on disk, you can have perfect memory safety, and all it takes is a keylogger to sink you.

I wonder if it would be possible to use 2FA, or some other means, such as requiring the user to click portions of a picture, or type in a punch code using their mouse.

The idea, is that this information would be used to either retrieve from the bitwarden server, or generate, a key mapping that obscures the real master password.

So if configured correctly, when I type in “BitwardenIsTheBest” I actually get “OvgjneqraVfGurOrfg” (rot 13 to make this example, but it could actually be “randomized” based on the additional input, rather than a fixed formula like rot13).

In this way, even if you keylog my “BitwardenIsTheBest” password, you have to additionally have an exploit which allows you to read my browser’s memory to pull out the keymapping that turns it into the decryption password “OvgjneqraVfGurOrfg”. This could conceivably be stored until the browser is closed/memory is freed.

This additional factor would also provide insulation from dictionary attacks, as pass phrases would be scrambled into nonsensical words based on the additional input (the keycode selected via mouse, or physical 2FA key).

This is a good nice-to-have!
However, I’m not sure how this could be implemented in the extension and web vault, as a website and extension might not have the permission to hide or encrypt the typed data.

But if it’s possible, I do wish to see this feature implemented soon!

Keepass has this feature right ?
I would also love to see this feature.

Yup, think so.
Since Keepass is open-source, implementing this feature in Bitwarden should be possible, as long as this topic gets enough votes…

1 Like

As an alternative suggestion in the meantime, some of the 2FA options don’t involve entering a code using the keyboard. Yubikey ($50) is inserted into your USB port and Duo (free for up to 10 users) uses a push notification sent to your phone. An attacker could still keylog your master password, but they wouldn’t be able to use it without your 2FA token as well.

That’s not really an alternative.

The issue is, if they’ve keylogged your master password, and they have a copy of the vault data, say from your computer, they have your data; 2FA or no 2FA. 2FA only helps prevent getting the data in the first place.

It doesn’t particularly matter that keypass is open source, though I’m sure that’s helpful. The idea here is overall relatively straight forward :slight_smile:

I actually don’t know what keypass does, I’ve never used it. However, if they’ve done something similar to what I proposed, that’s great :slight_smile:

Even if I have absolutely no idea if it’s possible, I really like the idea and voted. Just waiting for the Bitwarden staff to respond and see if it can be done.

This is the kind of features I’d like for bitwarden. More than drag and drop, and stuffs like that. The app is not on top about design but works perfectly, and I value security more than design for a password manager.

1 Like

I’m not sure I get your request. A Keylogger 'logs your keys", e.g. your keyboard input. It doesn’t matter what a application does with the input (you called it ‘obfuscation’). The weak point is not the browser or the data transmitted to your browser but the physical input that is logged. I’m not sure how you want to protect against that.
So, if the “additional input” you mention has “always to be the same”, it’s trivial to log that input too. You might think that it would require a “bitwarden specialized” attack rather then a generic keylogger but modern keyloggers log more then just key input: mouse movement and screenshots can be captured just as easy and are often used.
What you request is “security when the input device can not be trusted”. But as of today, no encryption method can protect against such things. Only authentication, e.g. using FIDO2 with keys protected on a secure enclave, can do what you wish. But authentication is not enforced (as you correctly mentioned) if you have access to the encrypted data.

What KeePass (with some addons - details of the implementation varry and from my research in the past years only a few actually offer a higher level of protection) or KeePassXC do is to re-encrypt your data with a new, random key every time using a composite key made of your master password and a random key. The random key is encrypted using the “next” OTP of whatever auth system you use (might be TOTP, might be something else - doesn’t really matter). Because of this you always need to “authenticate” in order to access your data. However: this actually just looks more secure. Because most people forget something very essential: we’re doing all that because we assume the system you’re working on is not to be trusted. If that is true however, then the attacker has not only access to your most recent copy (encrypted with a random key that he not yet had access to) but also the copy before, that you just recently accessed using your authentication (which the attacker now also has). Thus, while he may not access the latest version, he may access the version before.

If you can come up with an actual encryption that can not be attacked by logging your activity on a untrusted system you probably will win the CS award of the year.

So, don’t get me wrong: we all would like to have such security. But it doesn’t exist (yet). And what you suggested (and other solutions implement so far) doesn’t provide any meaningful solution to the initial problem that you have to trust your computer.

KeePass does not use any OTP internally to protect anything, but you case close. It does mix in the HMAC secret in a way that is similar to OTP, but is mixes the full strength of the secret. OTP is purely an authentication concept for online systems. While the underlying concepts are similar, authentication online processes can take advantage of features like rate limiting, which generally results in weakened concepts to offline protections. An example is that a nonce is very similar in concept to a salt, except salts have more bits of strength. A nonce only needs to be strong enough to detect a failed attempted and lock down an account. A salt can’t lock down anything and must protect the data against an unlimited attack. A nonce might be 80bits while a salt would be 128bits. Different threat model, similar concepts.

And this discussion is mostly moot because a keylogger means the system is compromised and decrypting sensitive state on a compromised system means you must assume that data is now also compromised. It at best gives a false sense of security.

Hey guys,

So, I think we can all agree that there are different degrees to which you can compromise a system. It’s true that implementing something like this wouldn’t prevent all forms of attack, however, it does raise the bar for what you need to successfully steal the data.

Keyloggers are kind of low hanging fruit that are often the easiest of many exploits to implement, because traditionally just about any application can read keys at any time, to listen for keyboard shortcuts. Newer systems like Wayland attempt to mitigate this to a degree, which should help, however, you can take things a step further; security and privacy are never a guarantees.

The way this works, you raise the bar by requiring that a secondary system, such as the display server’s output, be compromised, or easily available. You make the keys themselves worthless without the additional information provided via, say mouse clicks on a randomized virtual keyboard, or possibly a physical secondary device.

In other words, you might know my password is “password123”, but my encryption key is actually password123 modified by a pin code like 123456, which transforms it to the real password that’s used for decryption. This means that having the knowledge that I pressed the keys password123, only gives you one half of the puzzle to obtain the decryption password.

It’s not a matter of reenecrypting everytime, simply, changing the decryption password to be something different than the user’s real password, via a deterministic secondary factor, that’s harder to observe. That’s why this is keylogger resistance, and nothing more, it doesn’t guarantee safety from keyloggers, or a compromised system, but it certainly protects you from a class of keylogger malware.

1 Like