It didn’t take long for hackers to start cracking them, with over half of them cracked in almost no time.
There are two main reasons why such fast cracking was possible:
* the usage of the SHA1 function itself
* fast GPUs
The SHA1 function was mainly designed to replace the weaker function MD5. It was created to be fast, and indeed it is. On an AMD / ATI 7970 graphic card, “hashcat” (see https://hashcat.net/oclhashcat-plus/) calculates a bit over two billion SHA1 hashes per second. This means a lot of combinations can be tested in a very short time.
To overcome this “problem”, modern and more secure algorithms exist, such as the sha512crypt function used in Ubuntu and recent versions of Fedora Core Linux. Instead of 2 billion hashes per second, the same GPU card cracks only a bit over 12,000 sha512crypt combinations per second. For instance, checking one billion sha512crypt combinations takes about 24 hours; but less than 1 second for SHA1.
Because of today’s fast GPUs, one good advice when it comes to security is to choose a complex password, that:
* includes both uppercase and lowercase chars
* includes at least one space character
* includes numbers
* includes several symbols such as !@#
* it is not based on a known word
* it’s at least 12 chars in size, but the longer the better
Many of the people I know use passphrases that are between 20 and 50 chars in size. This is a good advice which makes it unlikely that even in the event that your password hash is leaked, nobody will crack it.
Imagine my surprise today when I tried logging into an older Hotmail account and got the following:
My previous password has been around 30 chars in size and now, it doesn’t work anymore. However, I could login by typing just the first 16 chars.
This limitation is well known (see Graham Cluley’s excellent post on the password limits of various services) however, what caught my attention was that by cutting the password to 16 chars, it would work.
To pull this trick with older passwords, Microsoft had two choices:
* store full plaintext passwords in their db; compare the first 16 chars only
* calculate the hash only on the first 16; ignore the rest
Storing plaintext passwords for online services is a definite no-no in security. The other choice could mean that since its inception, Hotmail was silently using only the first 16 chars of the password.
To be honest, I’m not sure which one is worse.
PS: My teacher said always think positively and try to end with an optimistic note. So here goes: “Thanks Google for GMail”.
2012 Sep 21, 21:10
MicroSOFT on Security
The password manager I use allows me to do all that is recommended including the ability to choose the length of the password, so I can adjust, but the fact Hotmail won't let me follow the advice of security experts and have a password that is at least 20 characters long is irksome, to say the least. I'm glad I have my gmail account to fall back on.
2012 Sep 22, 00:34
There are only two reasons someone trusts their passwords to the cloud:
2012 Sep 22, 01:04
This isn't a new issue btw.
Why can't my Microsoft account password have more than 16 characters?:
Re: This isn't a new issue btw.
Thank you, this clarifies the problem and confirms that Microsoft has been silently dropping any chars above 16 from the password for years.
Perhaps the "Trustworthy computing memo" did not reach people at Hotmail when it was sent 10 years ago.
2012 Sep 22, 02:21
They may have done the recalculation on a previous login. Stored the new hash in a separate field in the table, and then used that on your subsequent logins. Then on that next login just set to the old password hash value to null No way of knowing for sure, but I've used that solution when I needed upgrade hashes on customer accounts to something more secure. The bigger question here is why are you using hotmail instead of gmail ;-)
Re: Another solution
Thanks for the reply! Looks like they were just dropping any chars above 16 from the beginning. Funny there was no complain when I set a 30 chars passwords some time ago.
As for why use Hotmail, it's not that I'm really using it - but required for MSDN access.
2012 Sep 24, 22:54
Had you ever tried using only the first 16 characters (or, for a more general test, appending some garbage after your password to see if it gets ignored) before the change? I suspect they were _already_ only generating a hash on that much. Also, if your passwords rely on case variation for entropy, make sure they are actually case-sensitive - both of my banks are not (they also have a maximum length, though it's a bit more than 16)