Re: Validation flaw addressed in version 2.14

True, a factor 1000 is noticably better than nothing! - But is it good 
enough? Should it not be 10000 or 100000 today? What is the difference 
in time consumption of using SHA-256 to SHA-1? - It would really 
interest me how long a brute force attack takes (bypassing verification 
loops) for a combination of two words from the English dictionary, say 
of 100000 words, when being pushed through one of NSA's array of super 
computers - just to give an example. And what is the assumptive cost for 
this?

- Wolfgang

Rony Shapiro wrote:

> Hi Wolfgang!
>  
> My intuition is that 1000 iterations of a hash function slows down any 
> brute-force attack by three orders of magnitude. Even with today's 
> hardware, that's a significant speed bump.
>  
> Any more, and weak machines would take too much time for legitimate 
> authentication... again, by my intuition.
>  
> If anybody has some hard data that says otherwise, I'dbe glad to hear it.
>  
>     Rony
>
>     ------------------------------------------------------------------------
>     *From:* [email protected]
>     [mailto:[email protected]] *On Behalf
>     Of *Wolfgang Keller
>     *Sent:* Thursday, November 24, 2005 11:05 AM
>     *To:* [email protected]
>     *Subject:* Re: [Passwordsafe-devel] Validation flaw addressed in
>     version 2.14
>
>     A question that I like to raise here, and which perhaps the
>     experts might wish to answer, is whether 1000 turns of quick
>     machine code calculations does pose a serious obstacle against
>     brute force attackers equipped with todays growingly fast computer
>     hardware background? Perhaps the entire point of verification
>     loops is practically obsolete.
>
>     - Wolfgang Keller
>     (Director of JPasswords)
>
>     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
>>_______________________________________________
>>Passwordsafe-devel mailing list
>>[email protected]
>>https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel
>>
>>
>>  
>>