vortex5

Vortex level 5 consists in cracking a password hashed with MD5, which is called a preimage attack. No salt was used when applying the hash function, this makes it very easy by today's means to find the originating value.

The fastest way I found to achieve this is searching for the hash value with Google. Of course this will return lots of references to this level's solution, but you'll also get results for some websites that publish datasets of precomputed hashes, like for example md5crack or md5this.

Alternatively, you could crack the MD5 hash using some tool such as John The Ripper to perform a brute force attack. In the worst case this could result in computing all 62^5 combinations of the password (it was specified to be 5 characters long and consisting of a-zA-Z0-9). To restrict the number of tries, you can provide a wordlist of plausible passwords. Obviously, this will only generate a result if the password already existed in the list. This method works best when using real password data (e.g. from a leaked password database), since people tend to use similar patterns and also reuse their passwords.

Other tools such as RainbowCrack perform the attack using a rainbow table: a data structure used for the efficient storage of precomputed hash values. As for the websites mentioned above, you can easily get ahold of various tables, ranging from 50 to 500GB depending on the space of hashed values.

LinkedIn Password Data Leaked

As reported by several security related online portals, a file with approx. 6.5 mio SHA-1 password hashes from LinkedIn users is currently circulating the web. I could easily get ahold of a copy of that 250 Mb file through bittorrent and realized that my password matched an entry :(.

Here's how you can check:

$ echo -n "password" | shasum
$ grep 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 SHA1.txt
$ grep 000001e4c9b93f3f0682250b6cf8331b7ee68fd8 SHA1.txt 
000001e4c9b93f3f0682250b6cf8331b7ee68fd8

As mentioned here, a subset of the hashes are marked with 00000, presumably to identify already cracked passwords. You should therefore check both variants as shown above.

If your password matches, you should change your LinkedIn Password asap and then change your passwords everywhere where you reused it (especially for popular platforms like Facebook, Google or Amazon).

Did you just email me back my own password?!

A while ago I wrote a blog post about what precautions to take handling password data on your website. plaintextoffenders.com is a website dedicated to this issue. It nicely points out why storing passwords in plaintext really is such a bad idea. The main part of the website is a pillory of submitted websites which obviously apply bad password practices. There's for awareness...

Password Security 101 for Web Developers

Passwords are still the only mean of authentication for I'd say 99.95% of all online services including social networking sites, online shops and even e-banking applications. When you think about the consequences of a password theft, say for your personal email account, you'll soon realize that a password such as 123456, iloveyou or your mom's birthdate is totally insufficient... (see this and change your password everywhere if you get a match).

There a lots of articles that will tell you what a (more) secure password looks like (I especially like this one as well as it's illustration). And although many web sites will impose some password policy during registration that will reject any password unless it contains some digit or special characters, the choice (and the complexity) is ultimately left to the user. What's unavoidable is that users are almost certainly going to reuse at least one password sometime for one or the other online service. Haven't you also? (don't blush).

So what can you as a developer do about it? I don't know, but I can tell you what you should totally avoid if you don't want yourself and your company to be looked at as total newbs.

First realize that passwords are the user's good and you are due to treat that information with absolute care. Every single one of your clients has spent the effort of selecting some unnatural string, repeating the process until it complied with your password policy and spending the rest of the day trying not to forget it. This is the reason why user's will eventually reuse a password. So bear in mind, that you're not storing a user's password for your web application only, but most probably also for a number of other services the user has registered to. Respecting your client's integrity means that you will never disclose that data, not even internally within your company.

The most important precaution you should take when dealing with password data is: never ever store passwords in clear text. No system is safe enough, not even yours. And the risk's not worth it. If you don't know how to avoid storing passwords in clear text, learn about hash functions and salting.

Second rule: never ever send a password back to the user (for instance via email). This is totally unprofessional. You're not only showing your client that you're storing passwords in clear text (i.e. that you're a newb), you're also compromising his password by sending it over an unsecure channel.

I assume companies do this to reduce support cases related to lost passwords. They should rethink it all over. Recent attacks have shown how much damage is caused to the company (reputation) as well as to their clients by having confidential user data stolen. Think about RSA, the Sony Playstation network or recently Youporn (should you not know, the most popular pornographic website)...