validating the password in the In-Built crypt function in php - php

I used the crypt function with the blowfish algorithm(one-way hashing)and i saved my hashed string in db there no problem.
$hash=$2y$13$1wVxPniVSiKTjBmDxUhykeec08.v0UsujEkmhjHECIUgEiSuJFag
$actual=crypt("kumar",$hash);
These is how they used to validate the password is to took our current password and the hashed password which we can stored into the db.
On during these they compared with follwing code
public function compareString($expected, $actual)
{
$expected .= "\0";
$actual .= "\0";
$expectedLength = StringHelper::byteLength($expected);
$actualLength = StringHelper::byteLength($actual);
$diff = $expectedLength - $actualLength;
for ($i = 0; $i < $actualLength; $i++) {
$diff |= (ord($actual[$i]) ^ ord($expected[$i % $expectedLength]));
}
return $diff === 0;
}
It return only 0 or 1 when the password is correct or not.
But My question is on these how they matched the current password with the hashed password which we save in db.Because the current password only contains the string and the hashed password contains the cost,salt,hashed password.
Is that they validate the password only or only the salt or how they do it?
I want the flow of validation of passwords of In-built crypt algorithm.

For a starter I would recommend to use the functions password_hash() and password_verify() to check passwords, internally they use the crypt() function.
// Hash a new password for storing in the database.
// The function automatically generates a cryptographically safe salt.
$hashToStoreInDb = password_hash($password, PASSWORD_DEFAULT);
// Check if the hash of the entered login password, matches the stored hash.
// The salt and the cost factor will be extracted from $existingHashFromDb.
$isPasswordCorrect = password_verify($password, $existingHashFromDb);
But you seem to be interested in how the crypt() is able to verify the password with its hash. When you create the first hash, you pass in the crypt-parameters as the second argument, it contains the algorithm, the cost factor and the salt (the format is explained in this answer).
For verification you can calculate the hash again, but you need the exact same crypt-parameters, then you get a comparable hash. The first hash starts with the crypt-parameters, and the crypt() function extracts those parameters from the first hash, when you pass it as the second argument.
$2y$13$1wVxPniVSiKTjBmDxUhyke
In your example this part of the hash contains the crypt-parameters, it is the start of your hash and it is used by crypt() again to verify the password.

Related

How to match username with encrypted password on login [duplicate]

This question already has an answer here:
How to check a mysql encrypt value with a salt in PHP?
(1 answer)
Closed 9 years ago.
I would like to encrypt some passwords and put it in database. How do I keep this stuff in a database so I can retrieve the data if the owner matches.
Example
<?php
// some validations and other staff
$data = $_POST['input'];
$hash = crypt($data);
//then database insert code
?>
If I echo the $hash, it's giving me some encrypted data but when I refresh the page, the numbers are changing from time to time. How do I keep the data static? How will I tell the encrypted password that this was the owner when username and password entered.
Example
<?php
//time of encryption
$name = "someone";
$pass = "p1x6Fui0p>j";
$hash = "$pass"; //outcome of $hash e.g. $1$aD2.bo0.$S93XNfgOFLskhis0qjE.Q/
// $hash and $name inserted in database
?>
When the user tries to login with collect details, how will I refer $hash "$1$aD2.bo0.$S93XNfgOFLskhis0qjE.Q/" was equal to $pass "p1x6Fui0p>j" ?
crypt() has an unfortunate name. It's not an encryption function, but a one-way hashing function.
If you're using PHP 5.5+, just use password_hash and password_verify:
$hash = password_hash($data, PASSWORD_BCRYPT); // Bcrypt is slow, which is good
And to verify the entered password:
if (password_verify($pass, $hash)) {
// The password is correct
}
Now to answer your actual question: the purpose of password hashing is to authenticate users without actually storing their plaintext passwords. If hash(a) == hash(b), then you can be pretty sure that a == b. In your case, you already have hash(a) ($hash), so you just need to hash the inputted password and compare the resulting hashes.
crypt() does this for you:
if (crypt($pass, $hash) === $hash) {
// The password is correct
}
From the php crypt page
if (crypt($user_input, $hashed_password) == $hashed_password) {
echo "Password verified!";
}
You are not using your own salt, so for every call salt is automatically generated, and salted password is hashed. To get the same hash from this password, you need to run crypt with exact salt that was generated during first run.
Generated salt varies depending on algorithm used for hashing, but from your example it's MD5, and salt is delimited by first and third dollar sign inclusively:
$hash = '$1$aD2.bo0.$S93XNfgOFLskhis0qjE.Q/';
// \ salt /
So to get Exact same hash you need to call crypt($pass, '$1$aD2.bo0.$');
Remember that if you want to use your own salt, it needs to be in proper format for given algorithm. For best results use php 5.5+ password_hash mentioned by #Blender, and for older php versions there is password_compat library, with this you don't have to worry about proper salt format.

Does a salt and pepper password count as 96-bit encryption?

I have created this code for a salt and pepper password encryption. I assume this is a good way to encrypt passwords, but what level of encryption is this?
I first thought the 'bit' part was the length of characters used but I know that is incorrect. How many bits of encryption would this be?
PHP
function _h() {
$result = "";
$charPool = '0123456789abcdefghijklmnopqrstuvwxyz';
for($p = 0; $p<32; $p++)
$result .= $charPool[mt_rand(0,strlen($charPool)-1)];
return md5(sha1(md5(sha1($result))));
}
$salt = _h();
$pepper = _h();
$pass = $salt.md5($salt.md5($_POST['password']).$pepper).$pepper;
UPDATE
I understand this is not encryption, so I would not be able to say this is encrypted, but instead hashed. Is a hashed password with a salt and pepper secure enough to save a password?
There are quite a lot of problems with your scheme to hash a password.
PHP 5.5 will have it's own functions password_hash() and password_verify() ready, to simplify generating BCrypt password hashes. I strongly recommend to use this excellent api, or it's compatibility pack for earlier PHP versions. The usage is very straightforward:
// Hash a new password for storing in the database.
// The function automatically generates a cryptographically safe salt.
$hashToStoreInDb = password_hash($password, PASSWORD_BCRYPT);
// Check if the hash of the entered login password, matches the stored hash.
// The salt and the cost factor will be extracted from $existingHashFromDb.
$isPasswordCorrect = password_verify($password, $existingHashFromDb);
These functions will solve following problems:
They use a slow adaptable hash function (BCrypt), MD5 is ways too fast for hashing passwords.
They generate a safe salt from the random source of the operating system.
A pepper is not just a second salt, in contrast to a salt, the pepper is secret and will not be stored together with the hash. The same pepper will normally be used for all passwords.
There is no use in complicating the computation of salt and $peppr too much. After all the task is not the retrieval of what was originally used to produce these spices but trather the value of $_POST('a'] and you give away the $saltand $pepper as prefix/suffix (otherwise you couldn't use the stored valuelater to verify an input password with this hash). That being said, do as #zneak commented and use an expert library function.

Why isn't my PHP password hashing comparison working?

I have two functions, HashPassword() and ValidatePassword.
The first one hashes the password given on signup form with a dynamic salt and the second validates the password.
Basically, I am checking if the password hashes match they never do match. On my login form when I call the ValidatePassword() function I have tested echoing out the hashes in the ValidatePassword() to make sure I am splitting the hash in write place for comparing and I am but when comparing them, they echo out a different hash.
Probably easier to look at both functions to explain better.
<?php
// hashes a users password along with a dynamic salt
// dynamic salt is stored with users password and is seperated by a ;
function HashPassword($password){
// creates a dynamic salt
$DynamicSalt = uniqid('', true);
// hash the password given from user along with dynamic salt
$HashedPassword = hash('sha512', $password . $DynamicSalt);
// combine the hashed password seperated by ; then the dynamic salt to store in database
$final = $HashedPassword.';'.$DynamicSalt; // this value is stored in database like: c29fc9e4acdd2962c4db3f108bee728cf015c8f6388ab2cd4f21e405f9d2f13b2d53a1ab8629aa21c3453906a98aff0d4b9a0e14bfc2c553a4f9c7c0c32fc58a;4f91cfc746b426.53641182
return $final;
}
// validate password user entered ($password = password from user | $dbHashedPassword = hash from database)
function ValidatePassword($password, $dbHashedPassword){
// we need to get the password hash before the salt, (fetch just the first 128 characters from database hash)
$CorrectHash = substr($dbHashedPassword, 0, 128);
// get the dynamic salt from end of sha512 hash (
$DynamicSalt = substr($dbHashedPassword, 129, 151); // get just the dynamic salt part of the db hash
// hash the password from user and the dynamic salt which we got from the end of the hash from database
$TestHash = hash('sha512', $password . $DynamicSalt);
return ($CorrectHash == $TestHash);
// WHEN I ECHO OUT THE THREE VARIABLES $CorrectHash, $DynamicSalt and $TestHash
// THE $CorrectHash (from db, first 128 chars) is not the same as $TestHash
// AND TO MAKE SURE I AM SPLITTING THE HASH AND DYNAMIC SALT InN THE CORRECT PLACE I ECHO OUT
// $DynamicSalt and it is split in the correct place showing the 23 characters which the dynamic salt is 23 characters
// BUT WHEN I COMBINE THE $password and $DynamicSalt in $TestHash it shows a completely different hash from the $CorrectHash (which we got and split from database)
}
?>
I'm not sure what's wrong, but it seems I'm splitting the hash and dynamic salt in the correct place because when I echo out it shows the first 128 chars (sha512) then the dynamic salt (23 chars) but when echoing out the two 128 chars hashes they do not match (by this I mean they are completely different hashes).
It's probably something to do with how you're splitting the hash you're testing against. For instance, you're trying to get a salt that's 151 characters long.
Try this:
function ValidatePassword($password, $dbHashedPassword) {
list($CorrectHash, $DynamicSalt) = explode(";",$dbHashedPassword,2);
return $CorrectHash == hash("sha512",$password.$DynamicSalt);
}
if all your substr are correct you just forgot to append ";" . $DynamicSalt to the $TestHash
btw. this violates against the first database normalization rule: "values have to be atomic". the salt should be stored in a seperate field.

Confusing PHP BCrypt implementation

I'm trying to find a hashing algorithm to use to save my passwords in the DB (along with a salt). I found this on SO: How do you use bcrypt for hashing passwords in PHP?. The top answer has a library that seems to work. I'm just a bit confused by the verify method.
To run the script, the author of the library provides:
$bcrypt = new Bcrypt(15);
$hash = $bcrypt->hash('password');
$isGood = $bcrypt->verify('password', $hash);
The hash method takes the input string and hashes it using mcrypt + a salt. The result is returned to $hash. Then the verify method takes the same input as hash method + $hash. verify then calls mcrypt + the value of $hash (instead of some random salt) -- and somehow the results are the same $hash???
Simplified:
hash = password + salt
verify = password + hash
verify = hash <-- huh???
What did I miss?
ALSO:
I plan to modify the code such that hash method accepts a $salt parameter. I will make getSalt a public method. This way, I can get a salt, store it in the DB, store the hash in the DB, and use user's input + salt to see if it hashes to what I have stored in the DB. Any problems with this idea?
I'm not familiar with the actual bcrypt, but something along the following lines must be what happens:
When you create the "hash", $bcrypt->hash('password') returns a string that contains both the hash value and the initial salt.
When you subsequently say $bcrypt->verify('password', $mystring), the function first reads the salt part out of your input string, then creates the hash again with that salt, and finally compares that computed hash with the hash part of your input string.
In any salinated hashing scheme, you will always have to store the salt along with the hash value.
The hash in this case also contains the salt. It's concatenated to the beginning of the string, usually as something like $2a$12$SALT.... Passing the hash to verify is just done to use that salt value again, the rest of the hash is ignored. That also means you do not need to modify the function for use with salts, that's already part of the algorithm.

Am I using PHP's crypt() function correctly?

I've been using PHP's crypt() as a way to store and verify passwords in my database. I use hashing for other things, but crypt() for passwords. The documentation isn't that good and there seems to be a lot of debate. I'm using blowfish and two salts to crypt a password and store it in the database. Before I would store the salt and the encrypted password, (like a salted hash) but realized its redundant because the salt is part of the encrypted password string.
I'm a little confused on how rainbow table attacks would work on crypt(), anyway does this look correct from a security standpoint. I use a second salt to append to the password to increase the entropy of short passwords, probably overkill but why not?
function crypt_password($password) {
if ($password) {
//find the longest valid salt allowed by server
$max_salt = CRYPT_SALT_LENGTH;
//blowfish hashing with a salt as follows: "$2a$", a two digit cost parameter, "$", and 22 base 64
$blowfish = '$2a$10$';
//get the longest salt, could set to 22 crypt ignores extra data
$salt = get_salt ( $max_salt );
//get a second salt to strengthen password
$salt2 = get_salt ( 30 ); //set to whatever
//append salt2 data to the password, and crypt using salt, results in a 60 char output
$crypt_pass = crypt ( $password . $salt2, $blowfish . $salt );
//insert crypt pass along with salt2 into database.
$sql = "insert into database....";
return true;
}
}
function get_salt($length) {
$options = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789./';
$salt = '';
for($i = 0; $i <= $length; $i ++) {
$options = str_shuffle ( $options );
$salt .= $options [rand ( 0, 63 )];
}
return $salt;
}
function verify_password($input_password)
{
if($input_password)
{
//get stored crypt pass,and salt2 from the database
$stored_password = 'somethingfromdatabase';
$stored_salt2 = 'somethingelsefromdatabase';
//compare the crypt of input+stored_salt2 to the stored crypt password
if (crypt($input_password . $stored_salt2, $stored_password) == $stored_password) {
//authenticated
return true;
}
else return false;
}
else return false;
}
You really should have a look at PHPASS: http://www.openwall.com/phpass/ It's a password hashing framework using crypt() which is used in projects like Wordpress and phpBB.
There is also an excellent article on this website about password hashing, salting and stretching using crypt(): http://www.openwall.com/articles/PHP-Users-Passwords
UPDATE:
Currently there's an alternative for the PHPASS library. In the next version of PHP there are special functions for hashing and verifying passwords (using bcrypt): http://www.php.net/manual/en/ref.password.php. There is a compatibility library that implements these functions for PHP 5.3.7+: https://github.com/ircmaxell/password_compat
Your use of crypt() is fine. crypt($input, $stored) == $stored is the way it is designed to be used.
Your get_salt() function is not great, since it is using the often-poor rand() function. You should consider using a stronger random function, like openssl_random_pseudo_bytes(), instead.
The idea of a rainbow table is that an attacker can make a table with all possible passwords and their hashes at home.
E.g.
PASSWORD HASH
iloveSO gjroewjgo
password knbnogjwm
secret gjroehghe
jbieber rewgroewj
etc.
With this table, the attacker can quickly convert any hash to a password. Rainbow table uses some tricks so that not all hashes have to be stored, but it still computes all hashes beforehand.
By using a salt, even when storing it with the password, you make this much harder. Instead of hashing every word in a dictionary, the attacker would now have to hash every word with every salt. With a long enough salt, this gives enough combinations to make it unfeasible to compute all these hashes.
So a salt is not meant to be an extra password, known only to the application, it is meant to change the hash function so that it is non-standard.
This is a misuse of crypt() because you are using a deprecated primitive. Blowfish is very old, twofish is the replacement and even that is old because threefish is almost finalized. You should be using a member of the sha2 family, sha256 or sha512 are both good choices. crypt() can be used with sha256 or sha512, you should use the CRYPT_SHA256 CRYPT_SHA512 parameters respectively.
Also your salts have a very small entropy/size ratio, you are only using an alphanumeric set which is a joke because alphanumeric rainbow tables are the most common. You should be using a full byte which base256, and I recommend a salt that is 256 bytes long. Keep in mind all hash functions are binary safe by definition thus you shouldn't have to worry about null bytes and the like.
Use SHA-512 (if available) with a salt which includes time() and openssl_random_pseudo_bytes(). Crypt is consolidated / efficient because it returns the salt inserted with the hashed string.

Categories