Keylogger Resistance

Feature Requests Password Manager
1

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).

1 Like
2

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!

3

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

1 Like
4

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
5

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.

1 Like
6

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.

7

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:

8

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.

2 Likes
9

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.

10

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.

11

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.

4 Likes
12

Sorry if this is a dumb question but, why can’t windows simply have a secure keyboard feature/layer that disables any logging of key pressed while in use, much like the ones used by some sensitive secure Android apps?
My guess here is that some one is going to inform/confirm to me that said keyboard on ones phone is merely a so-called “secure keyboard” and can still be somehow compromised


13

Sorry if this is a dumb question but, why can’t windows simply have a secure keyboard feature/layer that disables any logging of key pressed while in use, much like the ones used by some sensitive secure Android apps?

Android doesn’t have a feature that prevents keylogging. It has a feature that prevents the keyboard from learning from you. That way if you say “My super secret X” there’s a greatly reduced chance someone could use a vulnerability in the way the keyboard tracks your behavior, or get “X” (which might be a password) out of the “known words”.

My guess here is that some one is going to inform/confirm to me that said keyboard on ones phone is merely a so-called “secure keyboard” and can still be somehow compromised


So yes, basically this.

There’s certainly more that can be done on the OS level to prevent key loggers from being as easy to write. Linux has come a long way with Wayland in filtering what applications can read the current keyboard input.

The idea here though was to add some additional noise they’d have to undo, that would be invisible to a keylogger. So you’d need a more advanced mechanism than “log all the keys and I can pick through and pick out things that look like passwords”.

14

I think the virtual keyboard is the best option (some random rotation of the characters is just too confusing). The web vault would be a great place to experiment.

Here is another thread about (which IMO could be merged):

https://community.bitwarden.com/t/virtual-keyboard-input-for-bitwarden-web-login-page-to-prevent-keyboard-sniffing/

15

I disagree, with some kind of “masking” keyboard sniffing could easily be replaced by click = screenshot based sniffing.

16

It may not be the most secure method, but it’s certainly the easiest way to deliver some keylogger protection without doing major changes in the backend code. The methods you mentioned are not “standard” as a virtual keyboard (which many people have already seen in banks), how much of code refactor will it really need to be safety implemented? What if someone comes with a better method, will it be easy to update it? What about attack surface?

A virtual keyboard would be only a matter of frontend design and some basic JavaScript, the use could be totally optional, just type with your normal keyboard if you want. And yes, they could use screenshot-based sniffing, but compare the models of hardware keylogger in this random shop I found, IMO a display based recorder is already another level of thread.

17

It may not be the most secure method, but it’s certainly the easiest way to deliver some keylogger protection without doing major changes in the backend code. The methods you mentioned are not “standard” as a virtual keyboard (which many people have already seen in banks), how much of code refactor will it really need to be safety implemented?

This is fairly trivial stuff – for some definition of trivial (like yes there’s work, but it’s not like building a whole new application, it’s augmentation of the authentication workflow). Effectively we’re just talking about a functional transform on bytes, strictly speaking there’s no reason the password needs to anything more than a normalized byte sequence (this is all math behind the scenes).

Even “real” passwords are fed through a key expansion algorithm for AES (and pretty much any other serious encryption algorithm). This would just be a preprocessing step based on some secondary data.

Figuring out how to generate the secondary data is the hard part. Rot13 isn’t a super practical example as it’s very local to US style keyboards, the English Alphabet, and Arabic Numerals. It’s also fixed so any attack on Bitwarden could just reverse the trivial transform.

I’m sure it’s this difficulty that’s (understandably) slowed any kind of progress on this. I mena, you could simplify this idea down to a dropdown that says “Pick your favorite color”. That would then select a different algorithm behind the scenes based on the colors, and potentially tied to the account. That would explode every garbage password by N*X “color/user” combinations.

Such an approach could make even “Password1” a difficult to crack password if Bitwarden’s servers were to have a leak, because “Password1” was “salted” another time with an unknown (okay, known to be in a set “N”) secondary secret, protect against software and hardware keyloggers (though not if the software keylogger could also screengrab), and just generally be a pain in the butt for an attacker.

The complexity introduced would be storing the selection of algorithms for a particular user, adding a dropdown, and then adding the algorithm to the JS library
 This is basic “development” work, modulo picking the algorithms to use to modify the password.

Really
 You could just use one key, and have this be a user selectable salt that gets mixed in with the password salt. So the “real” password for purposes of authenticating against a hash is “UserInput”.“User Salt”.“User Selected Salt”. Then you apply the same concept to the AES key extension (I’m assuming “User Salt” doesn’t play a role in this though I don’t know Bitwardens Crypto code – this is kind of “abstract”), and effectively “salts” the password input and decryption key.

Password1.Blue in effect becomes “Password1.<Bitwarden Stored Salt Correspoinding to User XXX’s Blue>”.

EDIT: The more I think about it if I ever decide to go back for a PhD this would be a really interesting space to explore :slight_smile:

A virtual keyboard would be only a matter of frontend design and some basic JavaScript

This is not trivial stuff. There’s a lot of complexity in making a virtual keyboard. I guess you could just “list keys” as buttons, and have a picker for keyboard “layout” that picks those keys. Then you’ve got to figure out how to make that all pretty.

models of hardware keylogger in this random shop I found

Most people I’d argue are not concerned about defending from hardware keyloggers. Software keyloggers are the bigger issue. It’s bad enough to have a machine compromised, if it’s been compromised at a hardware level, that’s an entirely different extreme.’’

EDIT: Also if your concern is a hardware based keylogger
 Just use your operating system’s onscreen keyboard. :slight_smile:

18

Is there a way to use Bitwarden (unlocking the vault and autofilling password) without keyboard events for the secrets being generated (and therefore being loggable)? In my understanding, there are still keyboard events when using autofill in combination with the Bitwarden extension.

I have a hardware key, and everytime I still have to type the master passphrase on the keyboard, or see password form fields getting filled automatically for me, I fill nervous. And the addition of Passkeys is not making the situation any clearer (to me).

Please issue at least guidance to users you want to understand the keylogger resistance properties of Bitwarden, and how to improve the posture (if that is indeed possible).

19

@Finch9183 Welcome to the forum!

My personal opinion is that all of these concerns are a bit theoretical. If someone has the capability to install a keylogger that logs all your activity on the system, then they also have the ability to read the contents of your computer memory (which contains all of your decrypted account credentials whenever you unlock your vault) — i.e., they don’t have to wait until you type or autofill your passwords in order to steal them.

Thus, the best security posture is to defend against malware and other unauthorized access to one’s devices.

20

That’s not true at all. It’s entirely possible you’re running a keylogger in user space. That doesn’t give the keylogger the power to read other process’s memory. For that, you’d need an exploit against the operating system (which is a significantly higher bar).