0
votes

I am looking for a password hash function that can stay with me for years. Picking the wrong one can be fatal, as it is impossible to upgrade the existing hashes without having the users log in.

It is often suggested to use bcrypt or sha256-crypt from glibc. These use key stretching, but I do not like the fact that I am unable to extend the stretching later on. One should be able to keep up with Moore's law.

Right now, I am considering the simple algorithm from the Wikipedia link, with SHA-256 for the hash function. That one allows me to just keep adding iterations as I see fit.

However, that algorithm is not a standard. It is therefore unlikely that I will ever be able to use the password hash with LDAP, htaccess, and so on.

Is there a better option available?

2
Without knowing a lot about the other constraints its impossible to say - its up to the applications involvde as to what they will supportsymcbean

2 Answers

0
votes

You should use SHA1 for password hashing. However, more than algorithm, you should also consider adding salt to passwords. Ideally a random salt should be created for each password and stored along with password.

This is to defeat rainbow tables.

Great discussion on this : Non-random salt for password hashes

0
votes

I may be coming at this from another angle, but if you are saying that you may have users who will not log in for long periods of time then that presents a big risk. The longer you allow a user to stick with the same password, the greater the risk of bruteforce from an attacker who manages to grab your password hash file somehow. Don't rely on security preventing that ever happening...

Hash functions don't go out of date that rapidly, so I would imagine you should be fine reviewing this annually, as hopefully you will have your users change passwords more often than that.

It all depends on your exact requirements, obviously, but have a think about it.

In general bcrypt or sha256 can suit the requirement nicely.

Update: You could think about popping this query across to security.stackexchange.com, as it is a security management question.