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
>
|