1

I'm looking at adding a Salt number to our user password table. We are saving the user passwords hashed as SHA256.

My question is would using the number generated from Mysql's UUID_SHORT() function for example '23154192415719433' be sufficient for a password salt?

So in my database the password 'Test123' would normally stored as 'd9b5f58f0b38198293971865a14074f59eba3e82595becbe86ae51f1d9f1f65e' by calling

SELECT SHA2('Test123', 256)

Will now be stored as 'e5e7b87ba899a6f9ad8f8e68e0b209b6923e546df70b8e4a47f996533827bce1'

SELECT SHA2('23154192415719433Test123', 256)
neildt
  • 4,275
  • 10
  • 49
  • 91

2 Answers2

0

Seeing as UUID_SHORT() returns a random 64-bit value, and SHA256 uses 256-bit encryption, you would be better off calling UUID_SHORT() four times and concatenating it as a binary value.

Dan
  • 9,855
  • 17
  • 45
  • Why would I need to concatenate it as a binary value ? – neildt Oct 07 '13 at 12:53
  • Well, I think concatenating four 64-bit values is the easiest way to get a 256-bit value. If you start manipulating them as numbers you would have to use ugly arithmetics or shift left/right operators. Concatenating binary values just seems a little prettier in my opinion. – Dan Oct 07 '13 at 12:58
  • But all I'm wanting to do is generate a random number (salt) to go alongside the password e.g '23154192415719433MyPassword'. – neildt Oct 07 '13 at 12:59
  • 1
    The problem is that UUID_SHORT() only gives you a 64-bit value, and you're using 256-bit encryption. In practice, this probably means nothing, but since you're already doing some effort to use 256-bit encryption, why not create a salt with just as many random bits? – Dan Oct 07 '13 at 13:03
  • Check out this ancient StackOverflow question: http://stackoverflow.com/questions/184112/what-is-the-optimal-length-for-user-password-salt - specifically, check out answer number 2. – Dan Oct 07 '13 at 13:14
  • Thanks. Is it sufficient to have the 256 bit Salt value like '23154192415719444231541924157194452315419241571944623154192415719447' stored in the user table, alongside the account it is used with. – neildt Oct 07 '13 at 16:10
  • also what field data type do you suggest I store the 256 Bit Salt value ? – neildt Oct 07 '13 at 17:12
  • Following on would this be sufficient... SELECT SHA2(SHA2(23154192415719433,256,) + 'Test123', 256). Basically I'm generating a unique number using UUID_SHORT(), and using SHA2 with 256 encryption to get the hash value. – neildt Oct 07 '13 at 22:05
  • @Tommo1977 - Actually, after reading a bit more about it, the only reason for having salts in a database, is to prevent dictionary attacks (i.e. users with same passwords resulting in the same SHA2 encrypted value). Thus, theoretically, you don't need any more salt values than the maximum number of passwords stored in your database, and simply prepending a users password with UUID_SHORT() should then be more than sufficient. But it's still an interesting discussion, so I'll leave my answer as it is. – Dan Oct 08 '13 at 07:28
-1

I expect that what you want is to

SELECT SHA2('password', 256)

give you always the same result which you can store/compare. UUIS_SHORT() does not return the same values after each invocation so store your passwords as hash as usual. What you can do to make it better is:

SELECT SHA2(CONCAT('password','some junk known only to you'),256)

You do need anything else.

Artur
  • 6,270
  • 2
  • 23
  • 34
  • 1
    OP is not asking how to encrypt a password using SHA2. He's asking what the best way to generate a unique and random salt for the password is. – Dan Oct 07 '13 at 13:00