Copy button appends spaces to long hashes

[Calos]

Hi,

First, thanks for the hash app. Seems to work well, just one issue. I use a long password, which often results in a 20+ character hash. When generating hashes this long, the app seems to append 4 trailing spaces, which obviously cause logins to fail if not removed.

The hash itself is correct. I do believe it has to do with the length of the generated hash, as trying it with a shorter password does not produce the trailing spaces.

Thanks!

[Calos]

Oh, for completeness - Motorola Droid running Cyanogen 6.1.2.

[phw]

Hi,

Interesting issue, thanks for reporting this. I will take a look at the
issue soon, but I will be traveling for the next two weeks.

Philipp
Am 21.06.2011 16:23 schrieb "Calos" <
reply@reply.github.com>:

Hi,

First, thanks for the hash app. Seems to work well, just one issue. I use
a long password, which often results in a 20+ character hash. When
generating hashes this long, the app seems to append 4 trailing spaces,
which obviously cause logins to fail if not removed.

The hash itself is correct. I do believe it has to do with the length of
the generated hash, as trying it with a shorter password does not produce
the trailing spaces.

Thanks!

Reply to this email directly or view it on GitHub:
#1

[phw]

Found the issue. This is actually a flaw in the algorithm and also present on pwdhash.com. The algorithm does under some circumstances append NULL bytes to the hash, if the hash is shorter than the input password. If you use Firefox you can even see the NULL bytes at the end of the hash on pwdhash.com, but they are ignored on copy'n'paste.

I've released version 1.2 which fixes the issue. You can download the APK here from github or from the Market. Thanks for finding this.

[Calos]

Thanks for the quick response!

Some other things that may be of interest...

As you mentioned you can see the nulls in Firefox, indicating it's an issue with the Stanford algorithm, I started playing around:

If I enter for a password 123456789012345678901234567890 or 30 "2" characters or 30 "1" characters and a couple other combinations, the trailing 4 characters in the hash are always "A" (both Chrome and Firefox). But if I take any of those and add a special to the end, the 4 "A" characters disappear... in Firefox, odd (apparently Unicode?) characters appear; in Chrome, the hash has no unusual trailing characters. Fortunately, copy'n'paste does eat the trailing Firefox nulls, as you say.

There certainly seems to be some errata in the Stanford algorithm. Unfortunately, that has to be replicated to maintain compatibility. Kind of scary, if you're dealing with a few different implementations. It looks like your app still generates compatible hashes for the cases that cause the trailing "A" characters.

I wonder, though, what implications the trailing A's have, in relation to cryptography? If nothing else, it's a signature that indicates an intercepted hash is probably generated by pwdhash. Beyond that, I imagine it's academic unless you are somehow being specifically targetted, as the work to crack the hash is a deterrent, so long as the pwdhash algorithm correctly implements MD5-HMAC.

Anyways, thanks again, both for the app and for the support!

[phw]

Yes, I had the same thoughts about the appended "A" character.

For some background without going into too much detail: The algorithm applies extra constraints to the generated hash based on what characters are present in the original password (e.g. special characters) by adding extras characters. But if the resulting hash is shorter than the original password those extras are empty resulting in the null bytes.

Now if you don't use any special characters in your original password all non alphanumeric characters get replaced by alphanumeric characters, again based on the (empty) extras. This replaces all the null bytes with "A".

I don't know enough too judge the implications on the cryptographic security, but it's obvious that the algorithm does not deal well with long passwords.