I was wondering if I use PHP's hash() function to generate sha512 hashes how would my MySQL table field look like in-order to be capable of holding the hashed password.
Here is my current MySQL password field layout
char(40)
A sha512 hash is represented as a 128 characters-long string.
For example, the following portion of code :
$sha512 = hash('sha512', "Hello, World!");
echo strlen($sha512);
Will give this output :
128
Which means your char(40) is far too small, and that you should use a char(128).
Another solution would be to store it in a binary form, and not a string -- which would mean 64 bytes.
But note it might be harder to deal with that representation, in some cases, I suppose.
Related
When I pass the clear password to check the login of the user and apply a md5() on the string, the md5 hash is equal to the md5 hash stored in the MySQL database (Login succeed).
But I don't want to transfert the user password in clear inside my POST function, so I decided to use cryptoJS to only send the key and then decrypt the password on the PHP server side.
The problem is, when I'm using the decrypted password, the md5 is different. This is weird because the clear password string is the same than the decrypted password, and the md5 hash is different.
By doing:
var_dump($clearPassword); //Hello.
var_dump($decryptedPassword); //Hello.
But:
var_dump(md5($clearPassword)); //3ea484671d7b00a1df4734ded1aa379c1.
var_dump(md5($decryptedPassword)); //470a1ad08cbdebe075214591ea20fec9.
As you can see, it's exactly the same string but the md5 hash is different, I've noticed that var_dump() give as an output:
string(16) for the $clearPassword;
string(32) for the $decryptPassword;
I tried to change the string encoding but there's no luck. Anyone can explain me why md5() behave like that with those same passwords string? thanks again.
the decrypted password IS NOT the same as the original. Check the length of the two strings, check the encoding, do a byte to byte comparison. "Hello\0" and "Hello \0" seems identical but they are not. Even "Hello\0" and "Hello\0\0\0" are not the same. Maybe the decryption algorithm gives a string length of 32 bytes.
I'm probably going to do like #fpierrat said, just encrypt in the client side and do a straight comparison of md5 hash in the PHP server.
I'm trying to use mcrypt_create_iv to generate random salts. When I test to see if the salt is generated by echo'ing it out, it checks out but it isn't the required length which I pass as a parameter to it (32), instead its less than that.
When I store it in my database table however, it shows up as something like this K??5P?M???4?o???"?0??
I'm sure it's something to do with the database, but I tried to change the collation of it to correspond with the config settings of CI, which is utf8_general_ci, but it doesn't solve the problem, instead it generates a much smaller salt.
Does anyone know of what may be wrong? Thanks for any feedback/help
The function mcrypt_create_iv() will return a binary string, containing \0 and other unreadable characters. Depending on how you want to use the salts, you first have to encode those byte strings, to an accepted alphabet. It is also possible to store binary strings in the database, but of course you will have a problem to display them.
Since salts are normally used for password storing, i would recommend to have a look at PHP's function password_hash(), it will generate a salt automatically and includes it in the resulting hash-value, so you don't need a separate database field for the salt.
Reading about generating salt using Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). This salt then will be appended to a string that needs to be hashed.
However, the salt generated by CSPRNG function (for PHP I'm using openssl_random_pseudo_bytes) is actually binary data.
Confused about how I should append this binary data to a string, I saw this PHP example for creating hash. It encodes binary data.
So I just wanted to know if that is what I need to do. I need to encode salt to get a string. Then I can append that salt to a string that needs to be hashed. Or are there other ways of adding salt to a string?
note I'm not hashing a password
If you need to hash a password, please use password_hash() and password_verify(), and probably add password_needs_rehash() - see http://de2.php.net/password_hash.
You might notice that these functions are available since PHP 5.5.0 - if you are using an earlier version of PHP, you can add this compatibility library to make it work with PHP starting at 5.3.7.
It can't get very much easier than that.
It's probably best to first convert your string into binary data using an encoding. UTF-8 encoding is probably best for most use cases. Don't forget to (at least) document which character encoding is used.
Now concatenate the salt and the encoded string. Again, you need to (at least) document the size of the salt. Please make sure you use concatenation of bytes, not strings. Bytes can have any value, including invalid characters, control characters etc.
After the concatenation you can feed the resulting byte array into the hashing function.
If you have trouble with byte concatenation in PHP, you could use hexadecimal values instead. But don't forget to convert them back into bytes before feeding them into the hash method.
I know the PHP function, password_hash outputs the algorithm, cost, salt, and hash all in one string so password_verify can check a password.
Sample output from PHP page:
$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a
so the $2y$ represents the algorithm, the 10 represents cost.
But how does password_verify separate the salt from the hash? I don't see any identifier separating the two afterwards.
For the bCrypt version of Password Hash.
Bcrypt has a fixed-length salt value. The crypt function which is what PHP calls internally when you're utilizing password_hash()/password_verify() with the default algorithm has a a 16 byte salt. This is given as a 22 characters of the custom base64 alphabet A-Za-z/. then it decodes the string into bytes as 22 B64 characters encode 16.5Bytes there is an extra nibble of data that is not taken into account.
For all other hashes the salt value is a defined set of bytes which are of course encoded into ASCII safe b64 and put after the $ sign and then the verifying function would only have to split the string into parts via the delimiter $ and then go for the third set of characters get the substr(0,B64_ENCODED_HASH_ALGORITHM_SALT_LEN). After that it would then pass the parameters it also got from the split string and pass those back into the password_hash function along with the password to check.
The string it gives you is defined by the hashing algorithm's standard in most cases but is almost always something to the pattern of
$<ALGORITHM_ID>$<COST_IN_FORMAT>$<BASE64_ENCODED_SALT><BASE64_ENCODED_HASH>$
I saw a 'confirm_code' column in a db table, and property of the column is varchar(100),
can you guys give me idea of a nice algo for a confirmation code ? Basically, it should consist of a random characters. The simplest things in my mind is just encrypting a string through md5 or sha1 but it won't fit because of the current column property.
An md5 hash should easily fit in a varchar(100)... in hex form an MD5 hash is typically 32 characters long.
You can generate unique ID's with uniqid().