[NT] Schneier's PasswordSafe Password Validation Flaw
- From: SecuriTeam <support@xxxxxxxxxxxxxx>
- Date: 8 Dec 2005 16:02:04 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Schneier's PasswordSafe Password Validation Flaw
------------------------------------------------------------------------
SUMMARY
" <http://sourceforge.net/projects/passwordsafe/> Password Safe is a
password database utility. Users can keep their passwords securely
encrypted on their computers. A single Safe Combination unlocks them all."
There is a design flaw in PasswordSafe, that allows users to perform Safe
Combination validation, which makes brute-force and dictionary attacks
much more effective.
DETAILS
Vulnerable Systems:
* PasswordSafe version 1.x
* PasswordSafe version 2.x
As described in PasswordSafe documentation, the PasswordSafe database has
the following format:
RND|H(RND)|SALT|IP|Name1|Password1|Notes1|...|NameN|PasswordN|NotesN
where
RND : 8-byte (64-bit) random value
H(RND) : hash value which depends on password, used along with RND to
check password (Safe Combination) validity
IP : 8-byte (64-bit) initial vector involved in encryption/decryption
process
SALT : 20-byte random value used involved in key derivation
PasswordSafe verifies password validity in following way:
bf_key = sha1 (RND | { 0x00, 0x00 } | PASSWORD);
bf_block = RND;
for (i=0; i<1000; i++)
bf_block = blowfish_encrypt (bf_block, bf_key);
finalhash = sha1_mod (bf_block | {0x00, 0x00});
Then, the 'finalhash' is compared to 'H(RND)' and, if there is equal then
the password is correct.
In pseudocode above sha1_mod() denotes usual SHA-1 computation with zeroed
initial state (this seems to be an implementation error).
The above key derivation function (KDF) uses so-called key-stretching
method to withstand password-guessing attacks. This method was introduced
in 1997 by Schneier, Kelsey, Hall and Wagner in "Secure Applications of
Low-Entropy Keys" paper.
However, PasswordSafe contains design flaw which allows attacker to verify
password validity without computing (relatively slow) KDF.
All records in PasswordSafe database are encrypted with Blowfish algorithm
in CBC (Cipher Block Chaining) mode.
According to the documentation, the first block contains the length (in
bytes) of encrypted data stored as 32-bit (4-byte) unsigned integer, fifth
byte holds type value for current record (in PasswordSsafe 1.x, it is
always zero), and three remaining bytes are zeros.
Encryption key is derived from user's password simply by computing
sha1(PASSWORD | SALT). Note that this is much simpler and faster than KDF
described above.
To check password for validity, the attacker can simply calculate the
encryption key, decrypt first encrypted block and check if three most
significant bytes are all zero.
The probability for this to occur on random password is about 2^(-24). If
this is true, then the attacker can check candidate password with full
KDF. Since full KDF will be called rarely (approximately 1 time per 16
million passwords), this protection against password-guessing attacks
becomes absolutely useless.
With PasswordSafe 2.x, slightly more effective attack is possible. The
first record of PasswordSafe 2.x database always has fixed length and type
(i.e. full plaintext block is known), and this allows to check passwords
with probability 2^(-64).
PasswordSafe is used to store sensitive data, and so the presence of such
flaws may help attacker to disclose user's logins, passwords and PINs by
implementing fast and effective brute-force and dictionary attacks.
Workaround:
Users should use strong passwords or passphrases.
ADDITIONAL INFORMATION
The information has been provided by <mailto:nfo@xxxxxxxxxxxxx >
ElcomSoft.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@xxxxxxxxxxxxxx
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@xxxxxxxxxxxxxx
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Prev by Date: [UNIX] sobexsrv Format String Vulnerability
- Next by Date: [NT] Total Commander WCX_FTP.INI FTP Account Information Weak Encryption
- Previous by thread: [UNIX] sobexsrv Format String Vulnerability
- Next by thread: [NT] Total Commander WCX_FTP.INI FTP Account Information Weak Encryption
- Index(es):