Skip to content

Password security

9. Jun 2012

There have been lot’s of security breaches quite recently, which led to data leaks in form of password stealing. I feel the need to cover this topic, like many others might did as well.

It’s actually the first topic that covers security.

For the users among you.

I don’t feel qualified enough to tell you how you should pick your passwords, but please consider:

– Do not reuse your password(s)
– Do not use passwords from sites that tell you how to make good passwords
– Do not give away your password(s)

Now for the technical folks and people who run services where people can register.

I don’t feel qualified enough to tell you how you should build the environments used by others or how you should set up your services, but you should feel responsible.

– Use state-of-the-art methods to protect the password
– Don’t set the maximum password length to low
– Don’t limit the password to [aA-zZ] and [0-9]

In the past I saw that passwords have been stored as plain text. $password was saved as $password. Some services like mailinglists still behave that way, mostly because it doesn’t protect anything and you are told to pick a password that isn’t to valuable. There are services that seem to store your password as plain text. For instance when you forgot your password and use the function “I forgot my password” and you get an email that contains your password it has been stored in plain text.

Should your password have been reset and you got a new one or you can enter a new password it seems to be better, but who knows.

Well, instead of storing passwords as plain text you can hash them. MD5 is still in use, although it has been cryptographically broken. $password gets saved as MD5($password). Arguably better than plain text. Still worse when the hash leaks somehow, because the hash can be precomputed for any string you can enter as password. That list is called rainbow table Maybe collisions can be found as well. So even when the attacker would be unable to find the correct password he could find a string that produces the same MD5 hash. Using SHA1 may improve the collisions issue, but doesn’t change the fact that the attacker can compute SHA1 hashes in advance. SHA1($password) is however better than MD5($password), like the SHA2 hash family should be safer than SHA1, because their digests contain more bits.

You can improve the issue with the precomputed by using a so-called salt. Considering you do the simplest sort you’d use a fixed salt. That salt would be for example “myservicesalt”. So you take the $password and append myservicesalt, then hash it with SHA1 (in this example). SHA1($password+myservicesalt). All precomputed SHA1 hashes would be of no use for an attacker. Consider that attacker has access to all files on your server so he knows the salt. He would have to compute the SHA1 hashes for all strings plus your salt. Therefor it’s better to have a long and unique salt.
If you use SHA1($password+fixed salt) you can be proud. You protect the passwords of your users to a degree that deserves the word protection.

Last year I proposed the SHA1($password+ fixed salt) to someone for “accounts” where the administrator creates and gives out the passwords, while the “accounts” would be valid for a short period of time. I was already aware of other hash function that are even better and that I will cover later in this text. For that time and the purpose it seemed good enough. The design, that depends on the “accounts”, to solve a certain problem should be reviewed by professionals. Maybe there are other ways. If we come to the point where that would matter. Maybe we get over it.

The problem with a fixed salt is that two users that use the same password, will have the same hash value. Also an attacker would have to compute all strings with the fixed salt only. When your service is too popular and the salt is known the creation of rainbow tables might be still reasonable for an attacker.

He’d have to run


and is most likely to be able to find passwords for different accounts with a single run.

This issue can be eliminated by using a variable salt. I think it is safe to keep the fixed salt, for example myservicesalt and append the variable salt to it. SHA1($password+fixed salt+variable salt). You may derivative the variable salt from the user name and the date the account was created. You should have enough entropy to avoid collisions in the variable salt. You store the variable salt along with the hashed password.

An attacker would have to run

SHA1(abcmyservicesalt+variable salt of user 1)
SHA1(bacmyservicesalt+variable salt of user 1)

SHA1(abcmyservicesalt+variable salt of user 2)
SHA1(bacmyservicesalt+variable salt of user 2)

Yes he would have to to this for all users. I’d consider SHA1($password+variable salt) to be state-of-the-art. SHA1 might be better replaced with SHA2 and once SHA3 is ready to be used it’s the way to go.

However MD5 and SHA1 are made for speed. With modern CPUs and tools that can use the GPU as well an attacker can compute thousands of million hashes per second. The GPU is a lot faster for those repetitive tasks than the CPU is. Also don’t forget that there’s the cloud. Well right buzzword, but an attacker can rent instances that do all the work.

One way to increase computing time is adding much longer salts to the password, but that doesn’t scale very well. Now there are other hash functions that are more suited for passwords.

One of them is PBKDF2 and another is bcrypt and just another is scrypt.

I’m not going to say that any of them is perfect and I don’t recommend one and I also don’t say that those are the only ones that can protect passwords, but note that they are harder to crack then SHA1($password+variable salt).

All of them can be tuned to take more computing time as technology evolves.

I hope this is helpful somehow.

From → General

One Comment
  1. It’s pretty long. I haven’t written anything that long so far.

    I used quote instead of code, because it looks better.

Comments are closed.

%d bloggers like this: