✅ Unlock vault with PIN

Would love to see this implemented too!

Preferably with more stages:

  • Soft-Password after X minutes inactivity (Pin, Fingerprint, short-pass)
    -> Combined with: Soft-lock after screensaver/lockscreen/…
    -> Optional: Hard-Lock after X minutes of soft-locked.
  • Unlock from Hard-Lock with fingerprint

This would be a fantastic option. Also, one could use an RSA key to authenticate and the key could be protected by say an OS level password protection.

Something else I forgot to ask: will the PIN be set locally (for each device) or cloud-synced as well? :thinking:

Now that there’s the desktop app for the 3 major platforms, there should be some way of doing so (at least for the desktop apps).

What about encrypting the encryption key with the pin code and only storing that in the bowser until unlock?

Please have three distinct operations.

  • Log in: Requires password and two-factor authentication. Identifies account and decrypts data.
  • Decrypt: Requires password. Decrypts data.
  • Unlock: Requires PIN or short password. Data already decrypted, merely allows access.

If Unlock fails a small number of times, or a suitable timeout has occurred, the decrypted data will be deleted, and a Decrypt operation will be required.


Also, on a device with sufficient processing power and with hardware-backed encryption available, the short password or PIN would also decrypt.

This will be available in the next version of the browser extension and desktop app. PIN can be any value that you want (unlike mobile app, which is 4 digits).



PIN code usage will persist since it encrypts the master key on disk. If you ever fully log out of the application, the PIN code setting will reset, requiring you to set PIN back up again when logging back in. This shouldn’t be too big of an issue since most users never log out of the application.

5 invalid PIN attempts will log the user out (requiring master password).


Awesome news! :grin:

I don’t get it. What does “it encrypts the master key on disk” mean? Will the master password be stored on the disk without a strict protection? Why? Why can’t you do it like in KeePass - EVERY TIME after you close a browser you must enter the master password but only once. Next unlocking is done via PIN.

I think five attempts are very bad for safety. I wouldn’t risk using a such unlock method. KeePass Quick Unlock give me one attempt only. I think it’s right.

it encrypts the master key on disk

It means that the PIN encrypts the master key. So yes, it is protected. By the PIN.

Protected by PIN ??? Are you kidding me? This will destroy the vault security!
And KeePass never stores the master password on a disk in any form. It stores the PIN inside the vault.

I don’t think you understand how locking works in Bitwarden. Whether the browser is restarted or the application locks due to a lock timeout, there is no difference. The application is locked, meaning all traces of the master key are purged from memory. Your proposed solution would not work.

If the vault is to be unlocked, the master key has to come from somewhere. In the case of unlocking with the master password it comes from what you are typing in. The the case of a PIN being entered, it comes from decrypting the master key that was previously encrypted while setting up the PIN. Your PIN should be strong enough to provide sufficient protection to the encrypted master key in the local environment.

kspearrin thank you, I understand how Bitwarden works. But I assumed this topic was about the fast unlock mechanism like the KeePass Quick Unlock. And the fact that you want to implement a different mechanism which I think is very dangerous.

The idea behind KeePass Quick Unlock is that you should enter the master password every time you start the program. After that, the master password is stored in memory (but not on a disk) and KeePass let you quick access to the password through the short PIN. It is convenient to combine this feature with automatic locking of the vault after 1-5 minutes of inactivity. When you close the program, the master password is deleted from memory and no one can access it.

In this way KeePass reliably protects the password database in your absence, but saves you the trouble of having to enter the master password multiple times during a single session of the program.

In this case I don’t understand the purpose of a PIN. I thought the goal was to free a user from entering a long password.

Based on what you are describing, it sounds like when KeePass is “locked”, it is only blocking an attacker from accessing secrets from the application’s UI. If the the encryption key is still available in memory, it would still be vulnerable to memory attacks.

Yes, this would be the goal. Some users have different threat models for online vs local attack vectors. If your threat model allows, a long master password should be used for logging in, while a shorter value could be used for a local PIN unlock. The PIN is essentially a local version of an alternate master password, which could be shorter for users.

As previously mentioned, if you log out of the application, all PIN settings are reset (meaning the encrypted master key is also deleted). Upon logging back in, PIN would have to be reconfigured.


kspearrin I have once again looked this discussion branch and as far as I can see the most of users have asked for the exact feature I wrote above (as in KeePass / Enpass). This is really not enough for desktop applications. Please think about it.

What about storing a version of the master key encrypted with the PIN code in memory instead of the hard disk? Wouldn’t that combine the advantages of both approaches?

Then we would have to persist the PIN somewhere on disk or else you’d have to re-setup PIN locking every time you restart the application.

kspearrin The PIN should be stored in the vault. Once you have entered the master password, the application can safely read the PIN.

Again, a master password would have to be entered to decrypt that data. When a Bitwarden vault is locked, the key derived from that master password is gone. Holding that in memory would mean the application is not locked. Providing a function to retain the master key in memory in some way is not what Bitwarden defines as a locked state and would be a definite security vulnerability.