2

I have a quick question for you guys:

I am tinkering with PHP (I am relatively inexperienced), and am interested in developing a secure password hashing system for use on my site. Through other articles and questions on SO, I have surmised that I should be using PHP's crypt() function for an implementation of BSD's bcrypt hashing algorithm.

My question to you pertains to the fact that, when I feed the function an initialization vector or password, inputs that are not base64 seem to return a "0" as the hash. Here is what I have implemented to work around this issue:

$salt = base64_encode(mcrypt_create_iv(16, MCRYPT_DEV_URANDOM));

and

$password = base64_encode($password);

Is there a danger of collisions or otherwise decreased security when I change the encodings like this?

My idea was that I would like to allow users to use any range of characters for their passwords (I will enforce a good password policy) without having to worry about my hash function returning an empty hash.

Is there a more simple or elegant way to do this? Should I perhaps be using a hash function that doesn't restrict my salt and password as much?

Thanks in advance for any help you can give me.

NCourts
  • 23
  • 2
  • 1
    There shouldn't be any use to `base64_encode` in your case as it is always reversible and make no difference in security. The use of [base64](http://en.wikipedia.org/wiki/Base64) is to make something binary to be represented as a string. – Alvin Wong Jul 23 '12 at 05:33
  • How about using this [Portable PHP password hashing framework](http://www.openwall.com/phpass/)? – Alvin Wong Jul 23 '12 at 05:35
  • "when I feed the function an initialization vector or password, inputs that are not base64 seem to return a "0" as the hash" ... What? – Ignacio Vazquez-Abrams Jul 23 '12 at 05:35
  • 1
    @IgnacioVazquez-Abrams From the php page for `crypt()`: "Blowfish hashing with a salt as follows: "$2a$", a two digit cost parameter, "$", and 22 digits from the alphabet "./0-9A-Za-z". Using characters outside of this range in the salt will cause crypt() to return a zero-length string." – NCourts Jul 23 '12 at 05:44

2 Answers2

1

Encoding it under base64 does not increase the chance of collision as it is simply a 1-to-1 translation. It does not reduce the password haystack whatsoever.

uzyn
  • 6,625
  • 5
  • 22
  • 41
  • Excellent, that definitely answers my question. Now I just have to figure out if I should change the method I am using to hash. Thanks for the quick response. :) – NCourts Jul 23 '12 at 05:50
0

For hashing in php, I suggest using the hash function. It takes an algorithm to use, so you can throw it through sha or anything else.

As for collisions, I wouldn't worry about them, it's highly unlikely that you will get impacted by collisions.

Aatch
  • 1,846
  • 10
  • 19
  • Is there something inherently wrong in using `crypt()`? I am certainly open to using another method, but is there a reason to use `hash()` instead? Is it just conventional? – NCourts Jul 23 '12 at 05:48
  • It's just generally easier. crypt is more complex because it is more general, allowing for encryption as well as hashing. Remember that encryption is not hashing. – Aatch Jul 23 '12 at 06:13
  • Got it. I will definitely play around with `hash()` then to see if it makes things any easier. I am familiar with the difference between the two terms after all of the lurking I have done. Thanks for the tip! – NCourts Jul 23 '12 at 06:31