phc-discussions - Re: [PHC] Are password trailing 0's a problem?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 8 Mar 2014 22:59:58 -0500
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Are password trailing 0's a problem?

On Sat, Mar 8, 2014 at 7:26 PM, Solar Designer <solar@...nwall.com> wrote:
> On Sat, Mar 08, 2014 at 04:06:11PM -0800, Jeremy Spilman wrote:
>> Just restating what CiC said in bullet form, but seeing it in pseudo-code
>> always helps me. When using password as the HMAC key, the way that PBKDF2
>> does, you end up with:
>>
>> if (password.length < block_size)
>>   password = password.pad(0x00, password.length - block_size)
>> else if (password.length > block_size)
>>   password = hash(password)
>
> Almost.
>
>> I guess it should be apparent that you can pass the hash of a password
>> longer than the block size in place of the password,
>
> Note that for this the padding should also be applied after the hash is
> computed, which is a detail you lost in the pseudo-code above.
>
>> but I bet 99.9% of people using PBKDF2 would be "shocked" to learn this.
>
> Right.  Here's an aspect that I haven't seen mentioned yet:
>
> Suppose someone reuses a >64 chars password on two sites, where e.g. one
> site uses raw SHA-256 and the other uses scrypt.  Suppose the raw
> SHA-256 hashes leak.  The password might be strong enough not to be
> cracked given the SHA-256 hashes (it's >64 chars).  However, the SHA-256
> hash may be used to log in to the site that uses scrypt.
>
> This is probably impractical given that passwords this long are
> extremely rare, but other than that it'd work.
>
> A hurdle is that the SHA-256 hash is likely to contain non-printable
> chars, which might or might not be possible to pass to the login form
> (and have them accepted and reach scrypt).
>
> Alexander

I'm watching the Duke Carolina game and drinking beer, so I probably
should avoid trying to say anything intelligent...

However, while this flaw is certainly not a critical weakness, and
obviously Escript in compatibility mode needs to continue using PBKDF2
as-is, for non-compatible mode, or entirely new password hashing
systems, should we live with such flaws or try to eliminate them?

I wrote up my HKDF2 code today, so I'm in a drunken mood to defend the
thought of dumping the cruft we've inherited and starting with
something new-ish (not new, just an upgrade to HKDF).

Bill