Re: Validation flaw addressed in version 2.14

Sometime in the past, there was a thought of moving values currently stored 
in the Windows registry into the PWS database (things relating to that 
particular database rather than across many - I see another discussion 
ensuing of which values should be included and which should not!).

If we are redesigning the database and losing backwards compatibility, would 
this be a good time to add one or more such records to the database after 
any new "header record" and before the "data records"?  Note: these must 
allow for the addition of many additional fields as PWS is expanded and 
enhanced and allow for prior (new) PWS versions to be able to ignore any new 
ones introduced e.g. V3.2 would understand, say, 10 fields; V3.5 would 
understand, say, 20 fields but V3.2 could still open a V3.5 database 
successfully by ignoring the extra 10 fields added since it was released, 
irrespective of the order of these fields in the record(s).

I notice that I have assumed that we would be going to V3 with this new 
format!

David

PS. If there was a vote, I would vote for AES rather than Twofish.

----- Original Message ----- 
From: "Dave Collins" <[email protected]>
To: <[email protected]>
Sent: Saturday, November 26, 2005 12:43 AM
Subject: Re: [Passwordsafe-devel] Validation flaw addressed in version 2.14


> Rony,
> I have thought for a few days about trying to make the db backwards 
> compatible and disprove Bruce's comment, however I now think he is right.
>
> As a starting point for a new format I propose:
>
> Random "Stretching" Salt 256 bits
> Salt 256 bits ?
> IV 256 bits ?
> Header record
> Data Record 1
> ...
> Data Record N
> MAC
>
> Where the encryption key is computed using the algorithm from page 351 of 
> Practical Cryptography.
>
> x[0] = 0
> x[i] = h(x[i-1] || passphrase || salt)
> Key = x[r]
>
> Where the number of rounds is to be choosen after further discussion about 
> performance,  r=1000,10000, etc
>
> The Header record would replace v2 first data record that had "!!!Version 
> 2 File Format!!!" as its name.
> I would say this should have a random block, a version number, followed by 
> preference in a simpler format to the data records.
>
> To verify the passphrase passwordsafe would generate the key and decrypt 
> the header record. If the header block does parse then we know the 
> password is incorrect.
>
> The data records would remain unchanged however I would like to propose 
> that autotype text and URL type bytes get added to the type list so we can 
> move them out of the notes field.
>
> The MAC would enable verification that nobody has tampered with your 
> password safe. I guess this should be HMAC using the hash alogirthm of 
> choice.
>
> As for algorithms I would obviously choose SHA-256 or SHA-512 for hash. As 
> for block cyphers I think I would like to use Twofish as its the little 
> sister of blowfish.  However I think AES would could be 'sold' easier to 
> potential users.
>
> Rony Shapiro wrote:
>> Hi,
>>
>> The good folks at elcomsoft have posted an item regarding a flaw in the
>> passphrase validation for all versions of PasswordSafe.
>> (http://seclists.org/lists/vulnwatch/2005/Oct-Dec/0046.html)
>>
>> Briefly, it's possible to take advantage of the database structure to 
>> bypass
>> the deliberately slow "key stretching" method used to verify the user's
>> passphrase, enabling a faster brute-force dictionary attack than was
>> intended by the designers.
>>
>> In release 2.14, I've implemented a partial fix to this, basically 
>> replacing
>> fixed data with randomness wherever possible in the first block. This is 
>> a
>> partial fix, but it's the most I can do without breaking backwards
>> compatability with existing implementations (and it seems that I've 
>> already
>> broken compatability with the Java version...).
>>
>> I'd like to ask this list for suggestions for (1) a better solution that
>> would keep compatability with previous versions (that is, that previous
>> versions 2.x of PasswordSafe will be able to read the new database, and 
>> (2)
>> a complete solution, unencumbered by backwards-compatability (that is, a 
>> new
>> version of the database format).
>>
>> Thanks to Jeff & Hagai for bringing the vulnwatch posting to my 
>> attention.
>>
>> Cheers,
>>
>> Rony
>>
>> P.S. - I've decided not to announce this to the user's mailing list for 
>> two
>> reasons: 1. The issue is a bit subtle and therefore difficult to explain.
>> Conversely, it's *very* easy to misunderstand as "passwordsafe's security
>> is/was broken". 2. The fix isn't a complete solution to the problem 
>> (yet).
>> Of course,



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click