Non-CP1252 characters in passwords are insecure
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
keepassx (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
I was reviewing the crypto code in keepassx for fun and discovered a flaw in the derivation of an encryption key from a password.
Summary:
Any characters in your password that are not found in codepage 1252 are silently squashed to '?' before the software generates the encryption key it uses to encrypt your data.
Affected versions:
I was looking at the source to keepassx 0.4.3-1ubuntu2 (as found in precise).
Judging by the comments in Kdb3Database.cpp I think that all versions since 0.3.1 are affected, and possibly earlier.
The function responsible is Kdb3Database:
To demonstrate this issue:
1. Create a password database in keepassx.
2. Protect this database with a password made up of a character from a non-Latin script. (You can do this by copying and pasting from the Character Map applet. You can probably type it if your input methods are set up suitably.) Note that you can press the eyeball button to see the character as you paste and confirm that the text entry box does appear to be handling the characters correctly.
3. Save the database and close it.
4. Re-open the database. Instead of the password, type a question mark.
5. Notice that the database opens successfully. (If you use any other Latin character, or get the length wrong, it doesn't.)
(You can do this with any length of password, provided you get the number of question marks right.)
Who is affected:
Anybody who uses keepassx password protection where their password is entirely made up of non-Latin characters.
Impact:
If your keepassx database is protected by a password made up of non-CP1252 characters, an attacker who can steal your database would be able to quickly break the password by a brute force attack.
Possible remedies:
- Patch Kdb3Database:
- Change your database password to one comprised entirely of characters found in CP-1252.
- Use key file protection as well as (or instead of) password protection, but bear in mind that an insecure password doesn't add much security.
- Migrate to a different password manager.
Further notes:
- Take care to not confuse keepass (keepass.info) with keepassx (keepassx.org). They are different codebases but their databases are compatible, up to a point.
- I note that keepassx 0.4.x is no longer maintained by upstream.
- I have not tried the keepassx 2.0 alpha.
- I have tried keepass2 2.18+dfsg-2 (from precise) and found that the above demonstration of this issue does not work, though I have not looked at its code.
- I suspect the same issue applies to the original v1 keepass software (keepass.info) but have not tried it as it is Windows only.
information type: | Private Security → Public Security |
Changed in keepassx (Ubuntu): | |
status: | New → Confirmed |
Ross, this is very interesting, nice work.
Because this is an intentional feature of the program, I'm choosing to not ask for a CVE number, and I'm also just opening the bug report for public view. This is likely a feature designed to ease inter-operation with the Windows program of similar name, and "fixing" this issue would likely break the easy movement of encrypted password stores.
At least once the trade off is publicly visible, users can choose to continue using keepassx or not as they wish, or modify how they use it, with knowledge of its limitations.
I'm curious if you can speak to the key derivation function used? Their website is remarkably information-free on the important parts of password storage and the corresponding keepass.info Windows-program has the rather terrifying "SHA-256 is used as password hash. SHA-256 is a 256-bit cryptographically secure one-way hash function. Your master password is hashed using this algorithm and its output is used as key for the encryption algorithms."
Thanks