Password Safe

Hi,

Paul is right in that the known plaintext in the beginning makes it a
*little* easier to attack, but that in principle, the same vulnerability
exists in 1.7.

However, to the best of my knowledge, this does not make the system
weaker than the underlying blowfish algorithm, in the sense that a
brute-force attack is the most effective known attack. I see no reason
to make the system stronger than blowfish. (What's good enough for Bruce
Schneier is good enough for me...).

A couple of comments:

1. My suggestion for adding a random block before the known text *does*
effectively hide the text, due to the way CBC works. You can look it up
in the RSA Labs crypto FAQ, or any basic cryptography textbook.
(however, as Paul pointed out, the system is not weaker, in principle,
than before, since identifying decrypted ASCII text is trivial)

2. The implementation of the password verification block is (a) flawed
(which is why Paul had to skip it - see notes.txt for details), and (b)
just a convenience, probably borrowed from somewhere else. Today, we
would probably use the HMAC algorithm for the same purpose, but HMAC was
published after PasswordSafe came out.

	Cheers,

		Rony

> -----Original Message-----
> From: passwordsafe-devel-admin@... 
> [mailto:passwordsafe-devel-admin@...] On 
> Behalf Of Paul Pluzhnikov
> Sent: Thursday, March 25, 2004 17:51
> To: passwordsafe-devel@...
> Subject: Re: [Passwordsafe-devel] security issue
> 
> 
> Ovidiu Gheorghioiu <ovy@...> wrote:
> 
> > But unless I'm missing something, an attacker does not need to go
>  > that route to verify a candidate password.
> 
> Indeed. The pwsafe-decode.pl that I wrote a while ago ignores the 1000
> blowfish encrypts, and decrypts the data just fine without it.
> 
> > This kind of attack may be possible even with V 1.7 files, 
> 
> It is possible.
> 
> > although harder since the first record is not constant, and an 
> > attacker will have a harder time 
> > deciding whether the decrypted data makes sense.
> 
> Like 'does the result look like ASCII'?
> There is nothing hard about that.
> 
> Rony Shapiro writes:
> 
> > In the meantime, here's something I think might help: If 
> the known text
> > ("!!! Version 2 File Format" etc.) is prepended by a block of random
> > data, 
> 
> This makes the attack only slightly harder:
> instead of decrypting just the first record, you'll have to
> decrypt the first and the second, which is hardly an 
> improvement at all.
> 
> Ovidiu writes:
>  > I think a fix for this kind of attack
>  > would be to combine the salt read from the file with the 
> result of the
>  > 1000x encrypt (not rand hash, for obvious reasons)
> 
> But the result of 1000x encrypts (of the rand) *is* the randhash!
> 
> I think the fix is to 1000x encrypt the 'salt + password'.
> Currently:
> 
> 1. read(rand);
> 2. read(randhash);
> 
> # the next step can be skipped, as pwsafe-decode.pl does
> 3. verify blowfish('rand + password')x1000 == randhash
> 
> 4. read(salt);
> 5. read(ip);
> 6. use blowfish('salt + password') to read the rest
> 
> Proposed change to step 6:
> 6. use blowfish('salt + password')x1000 to read the rest.
> 
> Of course, all backward compatibility with V1.7 or V2.0 will 
> be lost :-(
> 
> Cheers,
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Passwordsafe-devel mailing list
> Passwordsafe-devel@...
> https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel
>

Rony Shapiro wrote:

> However, to the best of my knowledge, this does not make the system
> weaker than the underlying blowfish algorithm, in the sense that a
> brute-force attack is the most effective known attack.

You are missing a point (I think).

There are multitude of ways to attack any given system, and the weakness
discovered makes one such attack easier than it ougth to be.

> I see no reason to make the system stronger than blowfish.

The 'sault' is added to the password to make pre-encrypted known
plaintext password dictionary text attack impossible, but it
doesn't affect secure-ness of the blowfish itself in any way.

If you remove the sault, you'll make *overall* system less secure.

By the same token, the system currently makes password dictionary
attack 1000 times easier than it ougth to be, making overall system
less secure (against that attack) than it could be.

Cheers,

Hi Rony,

This is indeed what I'm pointing out. To some extent, it is true that 
all password databases will be vulnerable to brute-force / dictionary 
attacks. However, what I'm also pointing out is that with a simple 
change (combining the output of the 1000x Blowfish encrypt into the 
salt) you can make this kind of attack 1000 times harder, so it might be 
worth doing. Furthermore, this seems to be the intent of the code, and 
maybe you should look at the original Counterpane version (I don't know 
how to get it) and check how they did things.

Here's an excerpt from PKCS #5 on the iteration count usage:

"Another approach to password-based cryptography is to construct key 
derivation
techniques that are relatively expensive, thereby increasing the cost of 
exhaustive search.
One way to do this is to include an iteration count in the key 
derivation technique,
indicating how many times to iterate some underlying function by which 
keys are derived.
A modest number of iterations, say 1000, is not likely to be a burden 
for legitimate parties
when computing a key, but will be a significant burden for opponents."

Really, why make the database 1000 times less secure if you can easily 
avoid it?

Regards,
Ovidiu

Rony Shapiro wrote:

>Hi,
>
>As I posted on the list, what you're pointing out is that passwordsafe
>databases are vulnerable to a dictionary (i.e., brute force) attack.
>
>I think we can live with that, especially since this "vulnerability" was
>also inherent in previous versions.
>
>	Rony
>
>  
>
>>-----Original Message-----
>>From: Ovidiu Gheorghioiu [mailto:ovy@...] 
>>Sent: Wednesday, March 24, 2004 18:03
>>To: ronys@...
>>Cc: passwordsafe-devel@...
>>Subject: Re: [Passwordsafe-devel] security issue
>>
>>
>>Rony,
>>
>>Thanks for the quick reply.
>>
>>The attack I was referring to has less to do with the known 
>>plaintext, 
>>it takes advantage of the ability to verify a password 
>>without having to 
>>go through 1000x Blowfish encrypts / decrypts. Given that a 1000x 
>>encrypt is present in the initial password verification step, 
>>it seems 
>>to me that if I'm able to verify a password without performing that 
>>expensive computation, the system is less secure than intended.
>>
>>In other words, the attack would proceed as follows:
>>
>>1) Pick a candidate password (brute-force or dictionary)
>>2) Skip randstuff, randhash from the file, read salt and ipthing (I'm 
>>using names from the code here)
>>3) Start decrypting the first (few) record(s) until it 
>>becomes clear if 
>>the password is good or not
>>4) If not, go back to 1)
>>
>>The essential part here is step 3). The known plaintext makes 
>>it easier 
>>to decide whether the password is good or not, but I could do 
>>without it 
>>and simply test for lengths and strings that make sense. If I have to 
>>read N bytes to make an accurate decision, I only have to do 
>>ceil(N/8) 
>>Blowfish decrypts to test the candidate password, instead of 1000 
>>encrypts or decrypts. Hence, the cracker's job becomes much easier. 
>>Random stuff at the beginning would do little to thwart this, since I 
>>could simply skip over it and go to the part that I can make 
>>sense of.  
>>At best, it would cost the attacker another couple Blowfish decrypts, 
>>still nowhere close to the intended 1000 (unless you're 
>>sticking in 8 K 
>>random bytes which would  be kind of excessive).
>>
>>If you take RSA's PBE recommendations in PKCS #5 
>>(ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2-0.pdf, I'm 
>>referring to the second method, the one recommended for new 
>>applications), they get the encryption key by applying a hash 
>>function 
>>1000 or more times, so an attacker has to go through that for each 
>>password. And SHA1 is slower than Blowfish (around 20 
>>microseconds/hash 
>>in Java here), so this slows down brute-force considerably. Btw, to 
>>implement that you still only need SHA1 and a good cipher, so 
>>you could 
>>have that for PasswordSafe. Alternatively, in the current method you 
>>could combine the output of the 1000x encrypt you perform to 
>>verify the 
>>"randhash" with the "salt" when obtaining the encryption key.
>>
>>I'm not into cracking ciphers, so I don't know whether the known 
>>plaintext creates additional problems, it might well be the case.
>>
>>Please let me know what you think.
>>
>>Regards,
>>Ovidiu
>>
>>
>>Rony Shapiro wrote:
>>
>>    
>>
>>>Hi Ovidiu,
>>>
>>>You have a point - the known plaintext in the first record is a 
>>>weakness in the system.
>>>
>>>The purpose of the text is primarily to "break" pre-2.0 in a 
>>>      
>>>
>>controlled 
>>    
>>
>>>and useful manner. That is, if someone mistakenly attempts to open a 
>>>2.x database with a pre-2.0 version of pwsafe, he will get garbled 
>>>view, with the first entry informing him of what the problem is, and 
>>>how to solve it.
>>>
>>>In the long run, I plan to minimize this weakness by 
>>>      
>>>
>>removing the long 
>>    
>>
>>>text, under the assumption that as time goes by, the chance 
>>>      
>>>
>>for such an 
>>    
>>
>>>error will become smaller.
>>>
>>>In the meantime, here's something I think might help: If the 
>>>      
>>>
>>known text 
>>    
>>
>>>("!!! Version 2 File Format" etc.) is prepended by a block of random 
>>>data, the CBC mode will ensure that the known part of the 
>>>      
>>>
>>text will be 
>>    
>>
>>>encrypted with an unguessable IV, thus protecting against 
>>>known-plaintext attacks. The main problem with this modification is 
>>>that it might break deployed 2.0 applications - they will fail to 
>>>identify the database as 2.0. Still, this might be worth it.
>>>
>>>What do you think?
>>>
>>>	Rony
>>>
>>> 
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: passwordsafe-devel-admin@...
>>>>[mailto:passwordsafe-devel-admin@...] On 
>>>>Behalf Of Ovidiu Gheorghioiu
>>>>Sent: Tuesday, March 23, 2004 17:29
>>>>To: passwordsafe-devel@...
>>>>Subject: [Passwordsafe-devel] security issue
>>>>
>>>>
>>>>Hi all,
>>>>
>>>>I think I've discovered a security problem with the passwordsafe db
>>>>format, particularly affecting version 2.0.
>>>>
>>>>I've been using the software for a couple of weeks (nice work!), and
>>>>recently it's become necessary for me to occasionally read my 
>>>>passwords 
>>>>on Linux. Since I'm using version 2.0 which is not yet 
>>>>supported in the 
>>>>Linux version, and I was looking for something fun to hack on, I've 
>>>>started exploring the feasibility of a Java version 
>>>>(initially reading 
>>>>the database only). So I've been going through the corelib 
>>>>source code 
>>>>to see what the file format is.
>>>>
>>>>The problem I've found has to do with the 1000x Blowfish encrypt: it
>>>>seems to me that this was put in to make brute-force (or 
>>>>        
>>>>
>>dictionary) 
>>    
>>
>>>>attacks on the passwords much harder. This is reasonable, I 
>>>>think this 
>>>>method is even recommended in some PKCS. But unless I'm missing 
>>>>something, an attacker does not need to go that route to verify a 
>>>>candidate password. Instead, one can ignore the rand stuff 
>>>>and rand hash 
>>>>altogether, read the "salt" and "ipthing" from the file, and 
>>>>proceed to 
>>>>decrypt the *constant* V2.0 header (or encrypt one and see if they 
>>>>match), since all that's needed is the salt, ipthing and candidate 
>>>>password. In other words, the problem here is that the salt 
>>>>        
>>>>
>>used for 
>>    
>>
>>>>decrypting records does not depend on the result of a 1000x 
>>>>        
>>>>
>>Blowfish 
>>    
>>
>>>>encrypt, so that security is lost (too much salt anyone?). 
>>>>This kind of 
>>>>attack may be possible even with V 1.7 files, although harder 
>>>>since the 
>>>>first record is not constant, and an attacker will have a 
>>>>        
>>>>
>>harder time 
>>    
>>
>>>>deciding whether the decrypted data makes sense.
>>>>
>>>>I'll be happy to demonstrate such an attack (one needing only a few
>>>>Blowfish encrypts and only one Blowfish key setup per candidate 
>>>>password) if you guys want me to. I think a fix for this kind 
>>>>of attack 
>>>>would be to combine the salt read from the file with the 
>>>>result of the 
>>>>1000x encrypt (not rand hash, for obvious reasons), and use 
>>>>        
>>>>
>>that for 
>>    
>>
>>>>further Blowfish encrypts.
>>>>
>>>>If I'm missing something that makes the attack impossible,
>>>>please let me 
>>>>know, it would be a good thing :)
>>>>
>>>>Regards,
>>>>Ovidiu
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.Net email is sponsored by: IBM Linux Tutorials
>>>>Free Linux tutorial presented by Daniel Robbins, President
>>>>and CEO of GenToo technologies. Learn everything from 
>>>>fundamentals to system 
>>>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638
>>>>        
>>>>
>>&op=click
>>    
>>
>>>>_______________________________________________
>>>>Passwordsafe-devel mailing list 
>>>>Passwordsafe-devel@...
>>>>https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>> 
>>>
>>>      
>>>
>
>  
>

Hi,

Now you've confused me. The key used to encrypt the file is salted: Key
= SHA1(password | salt), so that precomputed dictionary attacks are
infeasible. This is the scheme used for PasswordSafe since 1.7 at least,
up to and including the current version.

I agree that hashing (or encrypting, or whatever) this key 1000 times
makes a brute-force attack that much times harder, but I've not been
convinced that the current system is so weak that this is worth doing,
not because of the implementation (trivial), but because this will break
compatibility with all exisitng databases. 

> -----Original Message-----
> From: passwordsafe-devel-admin@... 
> [mailto:passwordsafe-devel-admin@...] On 
> Behalf Of Paul Pluzhnikov
> Sent: Friday, March 26, 2004 17:30
> To: ronys@...
> Cc: passwordsafe-devel@...
> Subject: Re: [Passwordsafe-devel] security issue
> 
> 
> Rony Shapiro wrote:
> 
> > However, to the best of my knowledge, this does not make the system 
> > weaker than the underlying blowfish algorithm, in the sense that a 
> > brute-force attack is the most effective known attack.
> 
> You are missing a point (I think).
> 
> There are multitude of ways to attack any given system, and 
> the weakness discovered makes one such attack easier than it 
> ougth to be.
> 
> > I see no reason to make the system stronger than blowfish.
> 
> The 'sault' is added to the password to make pre-encrypted 
> known plaintext password dictionary text attack impossible, 
> but it doesn't affect secure-ness of the blowfish itself in any way.
> 
> If you remove the sault, you'll make *overall* system less secure.
> 
> By the same token, the system currently makes password 
> dictionary attack 1000 times easier than it ougth to be, 
> making overall system less secure (against that attack) than 
> it could be.
> 
> Cheers,
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President 
> and CEO of GenToo technologies. Learn everything from 
> fundamentals to system 
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Passwordsafe-devel mailing list 
> Passwordsafe-devel@...
> https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel
>

Hi Ovidiu,

This certainly wasn't the intent of the original code, since if it were
done there, than it would be impossible to read databases without doing
the same.

I agree that this appears to give stronger security, but as I've said
before, I'm unconvinced that the current system is so weak as justify
the compatability breakage that such a change would entail.

	Cheers,

		Rony

p.s. - The passwordsafe-devel mailing list is set up such that all posts
by non-members need to be explicitly approved by me (to de-spamify it).
If you sign up to the list, I won't have to approve each of your posts
manually. Thanks.

> -----Original Message-----
> From: passwordsafe-devel-admin@... 
> [mailto:passwordsafe-devel-admin@...] On 
> Behalf Of Ovidiu Gheorghioiu
> Sent: Friday, March 26, 2004 17:44
> To: ronys@...
> Cc: passwordsafe-devel@...
> Subject: Re: [Passwordsafe-devel] security issue
> 
> 
> Hi Rony,
> 
> This is indeed what I'm pointing out. To some extent, it is true that 
> all password databases will be vulnerable to brute-force / dictionary 
> attacks. However, what I'm also pointing out is that with a simple 
> change (combining the output of the 1000x Blowfish encrypt into the 
> salt) you can make this kind of attack 1000 times harder, so 
> it might be 
> worth doing. Furthermore, this seems to be the intent of the 
> code, and 
> maybe you should look at the original Counterpane version (I 
> don't know 
> how to get it) and check how they did things.
> 
> Here's an excerpt from PKCS #5 on the iteration count usage:
> 
> "Another approach to password-based cryptography is to construct key 
> derivation
> techniques that are relatively expensive, thereby increasing 
> the cost of 
> exhaustive search.
> One way to do this is to include an iteration count in the key 
> derivation technique,
> indicating how many times to iterate some underlying function 
> by which 
> keys are derived.
> A modest number of iterations, say 1000, is not likely to be a burden 
> for legitimate parties
> when computing a key, but will be a significant burden for opponents."
> 
> Really, why make the database 1000 times less secure if you 
> can easily 
> avoid it?
> 
> Regards,
> Ovidiu
> 
> Rony Shapiro wrote:
> 
> >Hi,
> >
> >As I posted on the list, what you're pointing out is that 
> passwordsafe 
> >databases are vulnerable to a dictionary (i.e., brute force) attack.
> >
> >I think we can live with that, especially since this "vulnerability" 
> >was also inherent in previous versions.
> >
> >	Rony
> >
> >  
> >
> >>-----Original Message-----
> >>From: Ovidiu Gheorghioiu [mailto:ovy@...]
> >>Sent: Wednesday, March 24, 2004 18:03
> >>To: ronys@...
> >>Cc: passwordsafe-devel@...
> >>Subject: Re: [Passwordsafe-devel] security issue
> >>
> >>
> >>Rony,
> >>
> >>Thanks for the quick reply.
> >>
> >>The attack I was referring to has less to do with the known
> >>plaintext, 
> >>it takes advantage of the ability to verify a password 
> >>without having to 
> >>go through 1000x Blowfish encrypts / decrypts. Given that a 1000x 
> >>encrypt is present in the initial password verification step, 
> >>it seems 
> >>to me that if I'm able to verify a password without performing that 
> >>expensive computation, the system is less secure than intended.
> >>
> >>In other words, the attack would proceed as follows:
> >>
> >>1) Pick a candidate password (brute-force or dictionary)
> >>2) Skip randstuff, randhash from the file, read salt and 
> ipthing (I'm
> >>using names from the code here)
> >>3) Start decrypting the first (few) record(s) until it 
> >>becomes clear if 
> >>the password is good or not
> >>4) If not, go back to 1)
> >>
> >>The essential part here is step 3). The known plaintext makes
> >>it easier 
> >>to decide whether the password is good or not, but I could do 
> >>without it 
> >>and simply test for lengths and strings that make sense. If 
> I have to 
> >>read N bytes to make an accurate decision, I only have to do 
> >>ceil(N/8) 
> >>Blowfish decrypts to test the candidate password, instead of 1000 
> >>encrypts or decrypts. Hence, the cracker's job becomes much easier. 
> >>Random stuff at the beginning would do little to thwart 
> this, since I 
> >>could simply skip over it and go to the part that I can make 
> >>sense of.  
> >>At best, it would cost the attacker another couple Blowfish 
> decrypts, 
> >>still nowhere close to the intended 1000 (unless you're 
> >>sticking in 8 K 
> >>random bytes which would  be kind of excessive).
> >>
> >>If you take RSA's PBE recommendations in PKCS #5
> >>(ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2-0.pdf, I'm 
> >>referring to the second method, the one recommended for new 
> >>applications), they get the encryption key by applying a hash 
> >>function 
> >>1000 or more times, so an attacker has to go through that for each 
> >>password. And SHA1 is slower than Blowfish (around 20 
> >>microseconds/hash 
> >>in Java here), so this slows down brute-force considerably. Btw, to 
> >>implement that you still only need SHA1 and a good cipher, so 
> >>you could 
> >>have that for PasswordSafe. Alternatively, in the current 
> method you 
> >>could combine the output of the 1000x encrypt you perform to 
> >>verify the 
> >>"randhash" with the "salt" when obtaining the encryption key.
> >>
> >>I'm not into cracking ciphers, so I don't know whether the known
> >>plaintext creates additional problems, it might well be the case.
> >>
> >>Please let me know what you think.
> >>
> >>Regards,
> >>Ovidiu
> >>
> >>
> >>Rony Shapiro wrote:
> >>
> >>    
> >>
> >>>Hi Ovidiu,
> >>>
> >>>You have a point - the known plaintext in the first record is a
> >>>weakness in the system.
> >>>
> >>>The purpose of the text is primarily to "break" pre-2.0 in a
> >>>      
> >>>
> >>controlled
> >>    
> >>
> >>>and useful manner. That is, if someone mistakenly attempts 
> to open a
> >>>2.x database with a pre-2.0 version of pwsafe, he will get garbled 
> >>>view, with the first entry informing him of what the 
> problem is, and 
> >>>how to solve it.
> >>>
> >>>In the long run, I plan to minimize this weakness by
> >>>      
> >>>
> >>removing the long
> >>    
> >>
> >>>text, under the assumption that as time goes by, the chance
> >>>      
> >>>
> >>for such an
> >>    
> >>
> >>>error will become smaller.
> >>>
> >>>In the meantime, here's something I think might help: If the
> >>>      
> >>>
> >>known text
> >>    
> >>
> >>>("!!! Version 2 File Format" etc.) is prepended by a block 
> of random
> >>>data, the CBC mode will ensure that the known part of the 
> >>>      
> >>>
> >>text will be
> >>    
> >>
> >>>encrypted with an unguessable IV, thus protecting against
> >>>known-plaintext attacks. The main problem with this 
> modification is 
> >>>that it might break deployed 2.0 applications - they will fail to 
> >>>identify the database as 2.0. Still, this might be worth it.
> >>>
> >>>What do you think?
> >>>
> >>>	Rony
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>>>-----Original Message-----
> >>>>From: passwordsafe-devel-admin@...
> >>>>[mailto:passwordsafe-devel-admin@...] On
> >>>>Behalf Of Ovidiu Gheorghioiu
> >>>>Sent: Tuesday, March 23, 2004 17:29
> >>>>To: passwordsafe-devel@...
> >>>>Subject: [Passwordsafe-devel] security issue
> >>>>
> >>>>
> >>>>Hi all,
> >>>>
> >>>>I think I've discovered a security problem with the 
> passwordsafe db 
> >>>>format, particularly affecting version 2.0.
> >>>>
> >>>>I've been using the software for a couple of weeks (nice 
> work!), and 
> >>>>recently it's become necessary for me to occasionally read my 
> >>>>passwords on Linux. Since I'm using version 2.0 which is not yet
> >>>>supported in the 
> >>>>Linux version, and I was looking for something fun to 
> hack on, I've 
> >>>>started exploring the feasibility of a Java version 
> >>>>(initially reading 
> >>>>the database only). So I've been going through the corelib 
> >>>>source code 
> >>>>to see what the file format is.
> >>>>
> >>>>The problem I've found has to do with the 1000x Blowfish 
> encrypt: it 
> >>>>seems to me that this was put in to make brute-force (or
> >>>>        
> >>>>
> >>dictionary)
> >>    
> >>
> >>>>attacks on the passwords much harder. This is reasonable, I
> >>>>think this 
> >>>>method is even recommended in some PKCS. But unless I'm missing 
> >>>>something, an attacker does not need to go that route to verify a 
> >>>>candidate password. Instead, one can ignore the rand stuff 
> >>>>and rand hash 
> >>>>altogether, read the "salt" and "ipthing" from the file, and 
> >>>>proceed to 
> >>>>decrypt the *constant* V2.0 header (or encrypt one and 
> see if they 
> >>>>match), since all that's needed is the salt, ipthing and 
> candidate 
> >>>>password. In other words, the problem here is that the salt 
> >>>>        
> >>>>
> >>used for
> >>    
> >>
> >>>>decrypting records does not depend on the result of a 1000x
> >>>>        
> >>>>
> >>Blowfish
> >>    
> >>
> >>>>encrypt, so that security is lost (too much salt anyone?).
> >>>>This kind of 
> >>>>attack may be possible even with V 1.7 files, although harder 
> >>>>since the 
> >>>>first record is not constant, and an attacker will have a 
> >>>>        
> >>>>
> >>harder time
> >>    
> >>
> >>>>deciding whether the decrypted data makes sense.
> >>>>
> >>>>I'll be happy to demonstrate such an attack (one needing 
> only a few 
> >>>>Blowfish encrypts and only one Blowfish key setup per candidate
> >>>>password) if you guys want me to. I think a fix for this kind
> >>>>of attack 
> >>>>would be to combine the salt read from the file with the 
> >>>>result of the 
> >>>>1000x encrypt (not rand hash, for obvious reasons), and use 
> >>>>        
> >>>>
> >>that for
> >>    
> >>
> >>>>further Blowfish encrypts.
> >>>>
> >>>>If I'm missing something that makes the attack impossible, please 
> >>>>let me know, it would be a good thing :)
> >>>>
> >>>>Regards,
> >>>>Ovidiu
> >>>>
> >>>>
> >>>>-------------------------------------------------------
> >>>>This SF.Net email is sponsored by: IBM Linux Tutorials
> >>>>Free Linux tutorial presented by Daniel Robbins, 
> President and CEO 
> >>>>of GenToo technologies. Learn everything from 
> fundamentals to system
> >>>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638
> >>>>        
> >>>>
> >>&op=click
> >>    
> >>
> >>>>_______________________________________________
> >>>>Passwordsafe-devel mailing list 
> >>>>Passwordsafe-devel@...
> >>>>https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>> 
> >>>
> >>>      
> >>>
> >
> >  
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Passwordsafe-devel mailing list
> Passwordsafe-devel@...
> https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel
>

Rony Shapiro wrote:

> Now you've confused me. 

I don't see where ...

> The key used to encrypt the file is salted: Key
> = SHA1(password | salt), so that precomputed dictionary attacks are
> infeasible.

Correct.

> This is the scheme used for PasswordSafe since 1.7 at least,
> up to and including the current version.

Correct.

> I agree that hashing (or encrypting, or whatever) this key 1000 times
> makes a brute-force attack that much times harder, 

Correct.

> but I've not been
> convinced that the current system is so weak that this is worth doing,

The system is not weak if the user selects good password, but it
is not doing a good job of protecting the user who choose a bad
(prone to dictionary attack) password.

> not because of the implementation (trivial), but because this will break
> compatibility with all exisitng databases. 

It need not break backward compatibility: v2.1 client could easily
read v1.7 and v2.0 files.

What will break is the ability of v1.7 and v2.0 clients to see the
this is a 'Version 2.1 File Format' message when they decrypt v2.1 file.

BTW, if we are going to break this ability of older clients to
(partially) read future file versions, we should put a magic number
and a version ID into the file header *unencrypted*.

That way, when format changes again (and sooner or later it will),
the v2.1 client would still be able to tell "this is a v2.5 file
and I don't know how to decrypt it".

Cheers,

I don't want to get into the encryption discussion per se (although I
believe that if it makes a file harder to crack then it is "in principle" a
good thing) but I do believe that the last point is valid no matter what
change is made in whatever area to whatever program...

i.e. we should only "guarantee" backward compatibility [i.e. Vn.r can read
Vm.s files where either (n = m & r > s) or n > m] either directly or via a
supplied conversion utility.  We should never "guarantee" forward
compatibility!


----- Original Message ----- 
From: "Paul Pluzhnikov" <ppluzhnikov@...>
To: <ronys@...>
Cc: <passwordsafe-devel@...>
Sent: Sunday, March 28, 2004 4:48 PM
Subject: Re: [Passwordsafe-devel] security issue


> Rony Shapiro wrote:
>
> > Now you've confused me.
>
> I don't see where ...
>
> > The key used to encrypt the file is salted: Key
> > = SHA1(password | salt), so that precomputed dictionary attacks are
> > infeasible.
>
> Correct.
>
> > This is the scheme used for PasswordSafe since 1.7 at least,
> > up to and including the current version.
>
> Correct.
>
> > I agree that hashing (or encrypting, or whatever) this key 1000 times
> > makes a brute-force attack that much times harder,
>
> Correct.
>
> > but I've not been
> > convinced that the current system is so weak that this is worth doing,
>
> The system is not weak if the user selects good password, but it
> is not doing a good job of protecting the user who choose a bad
> (prone to dictionary attack) password.
>
> > not because of the implementation (trivial), but because this will break
> > compatibility with all exisitng databases.
>
> It need not break backward compatibility: v2.1 client could easily
> read v1.7 and v2.0 files.
>
> What will break is the ability of v1.7 and v2.0 clients to see the
> this is a 'Version 2.1 File Format' message when they decrypt v2.1 file.
>
> BTW, if we are going to break this ability of older clients to
> (partially) read future file versions, we should put a magic number
> and a version ID into the file header *unencrypted*.
>
> That way, when format changes again (and sooner or later it will),
> the v2.1 client would still be able to tell "this is a v2.5 file
> and I don't know how to decrypt it".
>
> Cheers,
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Passwordsafe-devel mailing list
> Passwordsafe-devel@...
> https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel

Hi,

When the 2.x file format was discussed, one of the requirements was that
1.x executables will "break" in a useful manner. If this wasn't done,
then any change in the format (including those suggested) would result
in a "incorrect passphrase" error if and when a user attempted to open a
2.x database with an old executable. Overly protective? Perhaps, but
that was the decision taken then. Perhaps after there will be more 2.x
users then 1.x, we'll be able to break this principle.

	Cheers,

		Rony 

> -----Original Message-----
> From: passwordsafe-devel-admin@... 
> [mailto:passwordsafe-devel-admin@...] On 
> Behalf Of DK
> Sent: Sunday, March 28, 2004 18:09
> To: passwordsafe-devel@...
> Subject: Re: [Passwordsafe-devel] security issue
> 
> 
> I don't want to get into the encryption discussion per se 
> (although I believe that if it makes a file harder to crack 
> then it is "in principle" a good thing) but I do believe that 
> the last point is valid no matter what change is made in 
> whatever area to whatever program...
> 
> i.e. we should only "guarantee" backward compatibility [i.e. 
> Vn.r can read Vm.s files where either (n = m & r > s) or n > 
> m] either directly or via a supplied conversion utility.  We 
> should never "guarantee" forward compatibility!
> 
> 
> ----- Original Message ----- 
> From: "Paul Pluzhnikov" <ppluzhnikov@...>
> To: <ronys@...>
> Cc: <passwordsafe-devel@...>
> Sent: Sunday, March 28, 2004 4:48 PM
> Subject: Re: [Passwordsafe-devel] security issue
> 
> 
> > Rony Shapiro wrote:
> >
> > > Now you've confused me.
> >
> > I don't see where ...
> >
> > > The key used to encrypt the file is salted: Key
> > > = SHA1(password | salt), so that precomputed dictionary 
> attacks are 
> > > infeasible.
> >
> > Correct.
> >
> > > This is the scheme used for PasswordSafe since 1.7 at 
> least, up to 
> > > and including the current version.
> >
> > Correct.
> >
> > > I agree that hashing (or encrypting, or whatever) this key 1000 
> > > times makes a brute-force attack that much times harder,
> >
> > Correct.
> >
> > > but I've not been
> > > convinced that the current system is so weak that this is worth 
> > > doing,
> >
> > The system is not weak if the user selects good password, but it is 
> > not doing a good job of protecting the user who choose a 
> bad (prone to 
> > dictionary attack) password.
> >
> > > not because of the implementation (trivial), but because 
> this will 
> > > break compatibility with all exisitng databases.
> >
> > It need not break backward compatibility: v2.1 client could easily 
> > read v1.7 and v2.0 files.
> >
> > What will break is the ability of v1.7 and v2.0 clients to see the 
> > this is a 'Version 2.1 File Format' message when they decrypt v2.1 
> > file.
> >
> > BTW, if we are going to break this ability of older clients to
> > (partially) read future file versions, we should put a magic number 
> > and a version ID into the file header *unencrypted*.
> >
> > That way, when format changes again (and sooner or later it 
> will), the 
> > v2.1 client would still be able to tell "this is a v2.5 file and I 
> > don't know how to decrypt it".
> >
> > Cheers,
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President 
> and CEO of 
> > GenToo technologies. Learn everything from fundamentals to system 
> > 
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Passwordsafe-devel mailing list 
> > Passwordsafe-devel@...
> > https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President 
> and CEO of GenToo technologies. Learn everything from 
> fundamentals to system 
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Passwordsafe-devel mailing list 
> Passwordsafe-devel@...
> https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel
>