1

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?

AndreS
  • 11
  • 1
  • Without knowing a lot about the other constraints its impossible to say - its up to the applications involvde as to what they will support – symcbean Mar 31 '11 at 12:28

2 Answers2

0

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

Community
  • 1
  • 1
Shamit Verma
  • 3,839
  • 23
  • 22
  • SHA-1 is designed to be fast, which makes it a poor choice for password hashing. – Mark Jun 28 '11 at 15:43
  • @Mark: Could you elaborate on that? – DuneCat Sep 13 '12 at 14:01
  • The goal of SHA-1 is to take a bunch of bytes and quickly produce a cryptographically secure hash. The "quickly" part means that brute-force searches are faster than they would be with a slow hash function. Your best bet is to use a key derivation function with lots of iterations, since they're specifically designed to take a long time to compute. – Mark Sep 13 '12 at 16:01
0

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.

Rory Alsop
  • 1,441
  • 25
  • 38
  • The whole idea of a good hash is that even if someone does grab the hashes, they wont be able to do a reverse lookup. Either way, lousy passwords will be crackable no matter what algorithm you're using. Lousy protocols using good hashes also will be vulnerable to replay attacks or pass-the-hash attacks. There's a lot more to it than just which hash to use. – Marcin Mar 31 '11 at 14:35
  • @Marcin - forget reverse lookup. I'm looking at the time angle as per the OP. Brute forcing happens - a better hash function makes it take longer, but the OP seems to be allowing very long time periods. I agree with your other points - and current thinking indicates bcrypt and sha256 are appropriate for most purposes now. – Rory Alsop Mar 31 '11 at 14:47
  • Why not have account expiration? – Slartibartfast Apr 01 '11 at 02:47
  • @Slartibartfast - see original question "...without having users log in" – Rory Alsop Apr 01 '11 at 07:48
  • Your answer makes good sense, but it avoids the basic question: is there a standardized hash function with upgradable key stretching? It seems to not exist, so based on your response I will instead go with the glibc sha-256 and just hope that it stays "strong". I am too uncomfortable doing my own algorithm, even if it seems better. – AndreS Apr 01 '11 at 07:59