2

Possible Duplicate:
How to securely hash passwords?

I have a website and on that website I use SHA-256 and salt my user's passwords. What I'm doing right now is padding each letter of the user's password with trash data before hashing it. The reason I do this is so if someone happens to get a database dump of my site(unlikely, but possible) brute forcers/dictionary attack tools like john the ripper won't work because the hashed password isn't actually a word from their word lists, but a jumbled version of it.

Is this a viable strategy or is there another way to prevent dictionary attacks? Some users have reported problems with their passwords, which may or may not be related to my "pre-hashing" method, but I was interested in looking into alternatives for hashing passwords. I cannot use blowfish with any secure number of rounds due to the necessity that password hashes calculate in a reasonable amount of time.

Are there any PHP implementations of that new SHA3 Keccak hashing algorithm or would this be a bad idea to use?

Community
  • 1
Tar
  • 347
  • 1
  • 4
  • 7
  • What horribly ancient server are you using that using bcrypt with a decent iteration count will result in an unreasonable amount of time? If this is truly the case, it is time to upgrade your server before thinking about anything else.. –  Oct 07 '12 at 03:05
  • The login time for the site doesn't matter, but I also have to implement bcrypt in java and logins need to be instantaneous, which they can't be, if I'm using a high number of rounds. – Tar Oct 07 '12 at 03:07
  • You are looking at a few seconds of delay per login for using bcrypt with a decent iteration count. Is it really that unacceptable? Users won't even notice the difference. –  Oct 07 '12 at 03:34

3 Answers3

2

You should not use SHA-3 yet. And let's not call it Keccak for clarity's sake, I can't recall what SHA-2 and SHA were originally called so I guess future readers won't know Keccak either.

More on-topic, your answer is here: How to securely hash passwords? This protects against dictionaries and all other possible attacks in the best currently known way.

Community
  • 1
Luc
  • 31,973
  • 8
  • 71
  • 135
0

Hash of any dictionary word should not be used itself in any password solution, but you can use salting to avoid that i guess, so different words get different hashes, even if the same password is repeated twice, two different passwd entry.

http://en.wikipedia.org/wiki/Salt_(cryptography)

These systems are still vulnerable against the rainbow table attacks, so you need to limit the #auths/second by entity, to mitigate this.

About the different SHA algos, more here:

http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html http://www.schneier.com/blog/archives/2012/09/sha-3_will_be_a.html

Istvan
  • 153
  • 1
  • 5
0

If someone gets a copy of your site, then presumably they'll also get a copy of the code that runs it, in which case they'll notice your password modification scheme. It then becomes trivial to modify their cracking dictionaries to compensate.

If on the other hand, they only get a copy of the database (and not your code), then any sort of hash customization will be sufficient to prevent any sort of attack. A popular option is to salt the hash with not only a random string but also a site-specific secret which is contained in the site code but not the database. This renders the database password hashes useless without also obtaining the secret key... which hopefully would be harder to come by.

Also, don't forget PBKDF2, a hash strengthening algorithm which makes dictionary attacks several orders of magnitude more expensive.

As for SHA-3, it's still a few years away from being anything even worth considering. First you need implementations to be written, tested, peer-reviewed, etc. The existing SHA-256 or SHA-512 are still considered more than safe.

tylerl
  • 82,225
  • 25
  • 148
  • 226