Does Your Password Contain Non-Latin Characters?

Joseph Bonneau, a PhD candidate at the Security Group, University of Cambridge Computer Laboratory, contacted us to report a problem he found with non-Latin character passwords (Unicode) on Gawker Media sites:

I discovered that, after creating an account with the password 'ДДДДДДДД', I was able to successfully log in by typing '簡簡簡簡簡簡簡簡,' as well as 'ႤႤႤႤႤႤႤႤ', '©©©©©©©©'. It turns out that any string of exactly 8 characters whose unicode code point is >= 128 will be accepted. I've looked carefully at the implementation of crypt in PHP and across several platforms I tried, this is not a library problem-somehow your server is converting all of the non-ASCII characters to some fixed value prior to calling crypt() with them. It is worth noting that 'ДДДДДДДx' is not accepted when 'ДДДДДДДД' is the registered password-so a check is still being done. However, if 'ДДДДДДДx' is the registered password then '©©©©©©©x' is accepted. The most plausible explanation I can come up with is that your code is mapping all non-ASCII characters onto some canonical character (maybe �), and thus ignoring the actual character value in the hash. I'd be

curious to see exactly how/where in your stack this occurs.

The issue was in jBCrypt, a library we use for password hashing, and is outlined here. The non-technical explanation is that this issue (outlined by Joe above) affects non-Latin characters (e.g Korean word for 'password': 비밀 번호), Latin characters with accent marks, and other characters that are not in standard English usage (e.g German: Füße).

How does this affect you? It does not affect most of our users — If you are not using non-Latin characters for your password, there is nothing to do (see wikipedia for more information on the characters that are not affected — US-ASCII). If you do use characters that are non-Latin, you should reset your password to ensure it is updated to fully support these special characters.

Joe did add one more comment: "I do think users are best to avoid non-ASCII though, since it's less portable." While is it not required, I do agree with him on this point. You can still create a very secure password using the US-ASCII character set.

As a side note, you should know that we do welcome suggestions to improve our platform. Joe is one of several to do so, and the suggestions are both taken seriously and much appreciated.

Thanks, Joe.



    So did you actually fix the problem after Joseph reported it?

      creating a product hash reduction that does not create any collisions (that is 2 keys that reduce to the same hash values) is not simple at all as stated in the article they are using a library which is not even gizmodo's task to rectify i reckon the best they can do is report it to the dev team of jbcrypt and let them handle it since they probably whats best to do to the library :)

        yeah sure, just like how if Russians were hacking into the US Military's Windows based Nuclear missile control system, they'd just sit back and wait for the windows update...

        obviously thats an extreme example... but the point still stands. telling the customer you are using some random third party library, so its their fault that your account is being hacked, is hardly a good excuse.

Join the discussion!

Trending Stories Right Now