78 000 passwords and password hashes stolen and published

Swedish(?) crackers have stolen and published a list of 78 000 MD5/SHA1 hashes and cleartext passwords. Almost all of the passwords belong to Finnish people, so unless you're a Finn, you probably don't need to worry. If you are, see this thread.

The reason I brought this up here is that we all, as web developers, can learn something from this. The first lesson is that there indeed are people who steal login information they can't use to get money. The second lesson is that you must always validate user input and salt your hashes.

The third lesson can be gained by analyzing the password list itself. People use very weak passwords!. Here's a list of common passwords from the list, which may or may not have short numeric strings attached to them. Most numeric strings were four numbers, so I'm guessing they could be using their cell phone or bank card PINs.

• the user's username
• the user's first name
• the name of a loved one
• a pet's name
• the user's phone number
• the user's social security number
• the user's birthday
• "salasana" (Finnish for "password", a lot of these on the list)
• "tietokone" (Finnish for "computer", a lot of these too)
• "villevalo" (See the Wikipedia article)
• "perkele" (Wikipedia)
• "pillu" (a very informal word for female genitalia. The male counterpart was found too)
• "helppomuistaa" ("easytoremember")

NOTE: The list above contains actual passwords from the list. WIthout knowing the username and the service they are used for, however, they are useless, so that's why I dared to post them. Besides, those passwords are so damn weak, that I think they had it coming.

The last one sums up what people feel about passwords -- they need to be easy to remember. They have no problem with security, since they don't believe they would ever be targets. The developer of the login system, however, has the power to decide what kind of passwords can be allowed. I recommend the common but not too common check that the password has at least one lowercase, one uppercase and one numerical character, and is at least eight characters long. I'm also starting to think that a dictionary check wouldn't hurt.

Also note that people tend to use the same password for multiple services. So if another service is cracked, it can cause additional work for you. On the other hand, if your service is cracked, it can even compromise people's emails and other sensitive information.

More: F-Secure

ready to be scared - read http://www.codinghorror.com/blog/archives/000949.html

That's not so scary after all. Salting is an easy way to beat precalculation of hashes. I highly recommend the article linked to from the codinghorror.com article: Enough with the Rainbow Tables: What You Need to Know About Secure Password Schemes.

I've come to the conclusion that something like the following might be a nice way to hash passwords:



The reason I've put the sha1 hash of the password inside the string to be hashed is because if someone did go through all the trouble of cracking the above string, they would still need to crack the actual password. This will buy some time.

The username is included so that if two people who have joined the same day happened to have the same password, their hashes would be different. Join date is there just to increase the size of the string to be hashed.

salt_file should be placed outside the root directory of the web site to reduce the risk of accidental exposure. The salt should be long and consist of (truly) random characters. A separate salt file also allows you to create expiring passwords: just have a script replace the salt file periodically.

Ideas? Anything to add?