KeePass   KeePass Help Center Home KeePass Home | Package Downloads | Flag Translations | Blocks Plugins  
Home Help Center Home | People Forums | Award Awards | Search Search  






Donate Donate
Locked

Security


Detailed information about the security of KeePass.


Key  Database Encryption

KeePass database files are encrypted. KeePass encrypts the whole database, i.e. not only your passwords. Your user names, notes, even the entry times and UUIDs, etc. are encrypted, too.

The databases are encrypted using one of the following block ciphers:

Cipher Block Size Key Size
Advanced Encryption Standard (AES / Rijndael) 128 bits 256 bits
Twofish 128 bits 256 bits

These algorithms are well-known, analyzed thoroughly and generally considered to be very secure by the cryptographic community (see [1] for comments by the NIST on AES for example).

KeePass 2.x Only
KeePass 2.x doesn't support Twofish, but additional encryption algorithms are available through plugins.

The block ciphers are used in the CBC (cipher-block chaining) block cipher mode. In CBC mode, plaintext patterns are concealed.

For both algorithms, a 128-bit initialization vector (IV) is generated randomly each time you save the database. This allows multiple databases to be saved using the same key without observable patterns being revealed.


Key  Hashing and Key Derivation

In order to generate the 256-bit key for the block ciphers, the Secure Hash Algorithm SHA-256 is used. This algorithm compresses the user key provided by the user (consisting of password and/or key file) to a fixed-size key of 256 bits. This transformation is one-way, i.e. it is computationally infeasible to invert the hash or find a second message that compresses to the same hash.

Please note that the recently discovered attack against SHA-1 [2] doesn't affect the security of SHA-256. SHA-256 is still considered as being secure [3].

Key Derivation:
If only a password is used (i.e. no key file), the password plus a 128-bit random salt are hashed using SHA-256 to form the final key (but note there is some preprocessing: Protection against Dictionary Attacks). This random salt prevents attacks that are based on pre-computed hashes.

When using both password and key file, the final key is derived as follows: SHA-256(SHA-256(password), key file contents), i.e. the hash of the master password is concatenated with the key file bytes and the resulting byte string is hashed with SHA-256 again. If the key file doesn't contain exactly 32 bytes (256 bits), they are hashed with SHA-256, too, to form a 256-bit key. The formula above then changes to: SHA-256(SHA-256(password), SHA-256(key file contents)).


Binary  Random Number Generation

We need to generate several random bytes (for the IV, the master key salt, etc.). For this, several pseudo-random sources are used: current tick count, performance counter, system date/time, mouse cursor position, memory status (free virtual memory, etc.), active window, clipboard owner, various process and thread IDs, various window focus handles (active window, desktop, ...), window message stack, process heap status, process startup information and several system information structures. Additionally, KeePass uses random bytes provided by the system's default CSP RNG.

This pseudo-random data is collected in a random pool. To generate 16 random bytes, the pool is hashed (SHA-256) with a counter to form the final 16 random bytes. The counter is increased after 16 generated bytes. This way, we can efficiently produce as many secure random bytes as we need.


Key  Protection against Dictionary Attacks

KeePass supports protection against guessing and dictionary attacks.

You can't really prevent dictionary and guessing attacks: nothing prevents an attacker to just try all possible keys and look if the database decrypts. But what we can do (and KeePass does) is to make it harder: by adding a constant work factor to the key initialization, we can make them as hard as we want.

To generate the final 256-bit key that is used for the block cipher, KeePass first hashes the user's password using SHA-256, encrypts the result N times using the Advanced Encryption Standard (AES) algorithm (called key transformation rounds from on now), and then hashes it again using SHA-256. For AES, a random 256-bit key is used, which is stored in the database file. As the AES transformations aren't pre-computable (key is random), an attacker has to perform all the encryptions, too, otherwise he cannot try and see if the current key is correct.

An attacker now needs much more time to try a key. If he can only try a few keys per second, a dictionary attack is not practical any more. N is a work factor, indirectly a time factor. A super computer can try a key a lot faster than a standard PC, but anyway testing one key with N transformation rounds will take N times longer than trying a key with no transformation rounds on the super computer.

By default, KeePass sets N to 6000 encryption rounds (full encryptions are meant; N has nothing to do with the internal encryption rounds of AES). This has been done in order to provide compatibility with the PocketPC version (PocketPC processors are slower, therefore the key computation takes longer).

If you are using KeePass on PC only, it is highly recommended to increase the number of key transformation rounds. You can change the number in the database options dialog. Right of the field for the rounds, you'll find a button. When clicking this button, KeePass computes the rounds number that leads to a 1-second delay. Waiting 1 second at database opening isn't a problem, but for an attacker of course it is. But, the number can be freely set to a number of your choice. The button only should give you a rough idea how many rounds can be computed in 1 second on your computer.

This protection feature is only useful when using master passwords; key files are random anyway, there's no need to transform the key file contents (guessing the key file contents is equally hard to a brute-force attack on the final key).

KeePass uses multi-threading to compute these rounds (the master key is split up to two parts of 128 bits, which is the AES block size). On dual/multi core processors, the computation can be twice as fast as on a single core processor.

KeePassX: In contrast to KeePass, the Linux port project 'KeePassX' only partially supports protection against dictionary and guessing attacks.


Application Protection  In-Memory Passwords Protection

While KeePass is running, sensitive data (like the hash of the master key and entry passwords) is stored encrypted in process memory.

This means that even if you would dump the KeePass process memory to disk, you couldn't find the passwords (at least not in plain text).

KeePass 2.x Only
By default, entry passwords are in-memory protected, the other fields not (like in 1.x). However, you can turn on in-memory protection for other fields in the database settings dialog (not recommended though, because of performance reasons).

For example, when you are copying a password to the clipboard, KeePass first decrypts the password field, copies it to the clipboard and immediately re-encrypts it using the random key.

Additionally, KeePass erases all security-critical memory when it's not needed any more, i.e. it overwrites these memory areas before releasing them (this applies to all security-critical memory, not only the password fields).

KeePass ≥ 1.15 and 2.x use the Windows DPAPI for in-memory encrypting the sensitive data. With DPAPI, the key for in-memory encryption is stored in a secure, non-swappable memory area managed by Windows. If DPAPI is not available or disabled (advanced KeePass options, by default using DPAPI is enabled), KeePass uses the ARC4 encryption algorithm with a random key. Note that this is less secure than DPAPI, mainly not because ARC4 cryptographically isn't that strong, but because the key for in-memory encryption is also stored in swappable process memory.


Key  Locking the Workspace

Locking the workspace closes the database file, and remembers the last view settings (i.e. which group and entries you selected, list position, etc.).

This provides maximum security: unlocking the workspace is as hard as opening the database file the normal way. Also, it prevents data-loss (your computer can crash while KeePass is locked, without doing any damage to the database).


Plugins  Plugin Security

Separate pages exist about the security of plugins: Plugin Security (KeePass 1.x), Plugin Security (KeePass 2.x).


Black Box  Self-Tests

Each time you start KeePass, the program will perform a quick self-test to see whether the block ciphers and the hash are compiled correctly and pass their test-vectors. If one of the algorithms doesn't pass its test vectors, KeePass will show a security exception message box at startup.


Terminal  Specialized Spyware

This section gives answers to questions like the following:

  • Would encrypting the configuration file increase security by preventing changes by a malicious program?
  • Would encrypting the application (executable file, eventually together with the configuration file) increase security by preventing changes by a malicious program?
  • Would an option to prevent plugins from being loaded increase security?
  • Would storing security options in the database (to override the settings of the KeePass instance) increase security?

The answer to all these questions is: no. Adding any of these features would not increase security.

All security features in KeePass protect against generic threats like keyloggers, clipboard monitors, password control monitors, etc. (and against non-runtime attacks on the database, memory dump analyzers, ...). However in all the questions above we're assuming that there's a spyware program running on the system that's specialized on attacking KeePass.

In this situation, the best security features will fail. This is law #1 of the 10 Immutable Laws of Security [4] [5]: "If a bad guy can persuade you to run his program on your computer, it's not your computer anymore".

For example, consider the following very simple spyware specialized for KeePass: an application that waits for KeePass to be started, then hides the started application and imitates KeePass itself. All interactions (like entering a password for decrypting the configuration, etc.) can be simulated. The only way to discover this spyware is to use a program that the spyware doesn't know about or can't manipulate (secure desktop); in any case it can't be KeePass.


References  References and Further Reading

[1] National Institute of Standards and Technology: Report on the Development of the Advanced Encryption Standard (AES) (PDF).

[2] Bruce Schneier's blog: SHA-1 broken.

[3] Bruce Schneier's blog: Cryptanalysis of SHA-1, with comments about the impact of that discovery and what to do now.

[4] Scott Culp, Microsoft TechNet Essay, 2000: 10 Immutable Laws of Security.

[5] Jesper M. Johansson, Microsoft TechNet Magazine, 2008: Revisiting the 10 Immutable Laws of Security, Part 1.









Valid XHTML 1.0 Transitional Document

Get Thunderbird

Get KeePass


KeePass is OSI Certified Open Source Software
Copyright © 2003-2009
Dominik Reichl, [Legal Contact / Imprint] [Disclaimer] [Acknowledgements] [Donate], Downloads hosted at

SourceForge.net Logo