16

Should I create the password column as a regular varchar and then insert like this: 

sha1($pass_string)

Or should I do something extra upon the creation of the table to make sure that password field is secure?

Thanks!

Genadinik
  • 18,153
  • 63
  • 185
  • 284

4 Answers4

15

It's a normal varchar field (40 characters) but if you want to set it more secure you should use salt.

http://highedwebtech.com/2008/04/25/season-your-passwords-with-some-salt/

Update :

WARNING : Hash password without salt is REALLY WEAK ! You should never use it !!

Password salting is the good way for doing it : password salting

as adviced by pst :

  • using SHA-1 and salt is the more naive but quite well secure approach.

  • using bcrypt :

it's the more secure approach :) because it use speed in order to make it more secure, bfish is a hash function built around the encryption method blowfish. (Seems than twofish exists too and should be the "modern" version of blowfish).

It's a version using a chain of SHA-1 so it's a intermediate solution, but allowing to set speed to your needs. In fact speed make weaker your security.

ykatchou
  • 3,667
  • 1
  • 22
  • 27
  • 2
    Also should use a different ("more computationally expensive") function such as `bcrypt` and/or use an HMAC-hash. –  Sep 22 '11 at 23:03
  • 2
    Yes, definitely salt your hashes. Also, if you use a different salt for each user, you help prevent Rainbow Table attacks: http://en.wikipedia.org/wiki/Rainbow_table – Mac Sep 22 '11 at 23:04
  • @pst : could you give more details ? :) – ykatchou Sep 22 '11 at 23:19
  • @ykatchou http://stackoverflow.com/questions/1561174/sha512-vs-blowfish-and-bcrypt (bottom of accepted answer) and http://www.binarylogic.com/2008/11/22/storing-nuclear-launch-codes-in-your-app-enter-bcrypt-for-authlogic/ -- it isn't that SHA isn't a secure hash, it's just that a naive single call is *just too fast*. Since `bcrypt` was already designed for this, I see no need to "roll another" (unless you're designing a new algorithm/approach). –  Sep 22 '11 at 23:24
2

You could also use the AES_ENCRYPT() function built into mysql for greater security. Link here

There is also a good how-to here explaining further: link

JM4
  • 6,740
  • 18
  • 77
  • 125
2

The manual contains a good explanation of what type of column to use.

Michael Mior
  • 28,107
  • 9
  • 89
  • 113
0

Most people save the hash as you have suggested. It's safe enough and simple, making it a good choice.

Note that all hashes can be cracked eventually, so any hash is better than none and SHA is strong enough.

Bohemian
  • 412,405
  • 93
  • 575
  • 722
  • 2
    This is worse than that -- without a salt a trivial rainbow table attack will easily break it. Also, a single SHA is less-than-ideal for passwords because *it can be computed extremely quickly*. (`bcrypt` and HMAC can help address that.) –  Sep 22 '11 at 23:01
  • is hmac usefull for data smaller than one block ? – ykatchou Sep 22 '11 at 23:21
  • @ykatchou Oops, the comment is slightly incorrect. [HMAC-SHA1](http://en.wikipedia.org/wiki/HMAC) isn't designed to "help" with the speed, but what it can do is add another level of hardening with a server-secret key. –  Sep 22 '11 at 23:52
  • @pst : thanks to you, i discover bcrypt :) which help with the speed ! – ykatchou Sep 22 '11 at 23:54