I'm trying to transition to Blowfish for an authentication system. Bear with me, I'm not a cryptographer and my understanding of Blowfish is not quite there yet.
The current setup uses sha1 and salts. The salts are generated for each user and stored in the database. It boils down to this:
$salt = $this->getSalt($username);
$hash = sha1($password . $salt);
if ($hash == $hashInDB)
{
// user is authenticated, set session id etc ...
}
The getSalt() method gets the salt stored in the database for the specified user.
Now if I understand everything correctly, with crypt I should be doing:
$salt = '$2a$07$' . $this->getSalt($username) . '$';
$hash = crypt($password, $salt);
if ($hash == crypt($password, $saltInDB))
{
// The user is authenticated, set session id etc..
}
To clarify, for the second example the $saltInDB variable, is a value like `'$2a$07$arandomsaltcreatedatregistration$'.
Am I doing it right?
Your example is almost correct.
When you create a hash with the crypt() function, you will see that the used parameters (algorithm, cost and salt) are part of the generated hash (the begin of the hash):
$2a$07$LCzy1mE0b9lS8Uyx9HEeUgHm8zH1iDDZ5...
That means, you can replace $saltInDB with $hashInDB, the crypt() function will extract the needed parameters automatically from $hashInDB. This also answers your question about storing the salt, just store the hash value in the database, the salt is included there. And yes you should generate a new salt for each password.
The '$' after the salt is not needed.
More information about how to generate a bcrypt-hash you can find here, if you are looking for a well established library, i can recommend phpass.
Related
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.
i just get one function from this site which describe that how to generate secure password using hash.
function is bellow
function hash_password($password, $nonce) {
global $site_key;
return hash_hmac('sha512', $password . $nonce, $site_key);
}
i am using this function like
$salt = sha1(rand());
$salt = substr($salt, 0, 4);
$site_key="site.com";
$pass=hash_password($pass,$salt);
it generate random text on each time.
but i am unable to verify that password in database, as in database password is stored and this generate random text every time.
i want to know how can i use this function to
Store Password in Database at time of user creation
Verify Password from database at login
or
is there any other secure way?
Thanks
You need to store the random string ($nonce I presume) in your database as part of the data, together with the resulting hash. Otherwise, you simply don't have enough information to validate the password.
Store the random generated string along with the password into user's row on the db or hardcode the salt and use always the same salt instead of changing it everytime.
If you generate a new salt then the hash will change everytime you calculate it (and since it is a random value you cannot get it back...).
By the way, why not a simple MD5?
$pass = md5( $pass.$site_key );
Edit: please don't do that (the md5 thing I mean)! Mine here is an old and wrong suggestion. Find an updated resource online and choose a secure algorithm if you need to store passwords (php now also has password hashing and verifying functions that should be secure, https://www.php.net/manual/en/function.password-hash.php, check in the comments for further suggestions).
I'd like to use Portable PHP password hashing framework to hash passwords. But I find that its demos don't use salt for hashing a password. But it use a dummy salt for checking password which I find it strange and I don't understand this idea at all,
$dummy_salt = '$2a$08$1234567890123456789012';
if (isset($dummy_salt) && strlen($hash) < 20)
$hash = $dummy_salt;
I wonder, if I want to use convention method which I can generate the unique salt and store it for each user in my database, how can I use Portable PHP password hashing framework to generate salts?
This is the function I use to hash passwords but I have been told that sha512 has the same issue as sha1, wise to trust the expert like Portable PHP password hashing framework,
function hash_sha512($phrase,&$salt = null)
{
//$pepper = '!##$%^&*()_+=-{}][;";/?<>.,';
if ($salt == '')
{
$salt = substr(hash('sha512',uniqid(rand(), true).PEPPER_KEY.microtime()), 0, SALT_LENGTH);
}
else
{
$salt = substr($salt, 0, SALT_LENGTH);
}
return hash('sha512',$salt.PEPPER_KEY.$phrase);
}
Let me know if you have any idea. Thanks.
From the phpass article linked to from that page:
Besides the actual hashing, phpass
transparently generates random salts
when a new password or passphrase is
hashed, and it encodes the hash type,
the salt, and the password stretching
iteration count into the "hash
encoding string" that it returns. When
phpass authenticates a password or
passphrase against a stored hash, it
similarly transparently extracts and
uses the hash type identifier, the
salt, and the iteration count out of
the "hash encoding string". Thus, you
do not need to bother with salting and
stretching on your own - phpass takes
care of these for you.
...so it's not surprising that the examples don't use salting! You may be over-seasoning your code.
The code sample with the dummy salt is an example of how to prevent a timing attack by making sure that whether a user exists or not, the validation of the user takes the same amount of time, effectively by doing a dummy authentication for non-existent users. It needs a dummy salt because if the user doesn't exist, it won't have a stored salt to use.
I have a password being passed from my iPhone app to the database via a php script, user.php.
The variable $pass is populated by the following:
$pass = str_replace("'", "", $_REQUEST['pass']);
How can I encrypt this before it's inserted into my database? I've read a little about the different techniques, but looking for the best way to manage this.
Thanks to everyone.
While the answer below is technically still correct, php has new recommendations with regards to the hashing algorithms to use. Their recommendation, as of php >= 5.5.0, is to use the password_hash and password_verify functions to hash and verify hashed passwords . As an added benefit, these functions automatically include an individualized salt as part of the returned hash, so you don't need to worry about that explicitly.
If you don't care about retrieving the actual password's value (from the database encrypted value), you can run a one-way hash algorithm on it (such as sha1). This function will return a specific length string (hash) which cannot be used to find the original string (theoretically). It is possible that two different strings could create the same hash (called a collision) but this shouldn't be a problem with passwords.
Example:
$pass = sha1($_REQUEST['pass']);
One thing, to make it a little more secure is to add a salt to the hash and run the hash function again. This makes it more difficult to generate a password hash maliciously since the salt value is handled server-side only.
Example:
$pass = sha1(sha1($_REQUEST['pass']).sha1("mySalt#$#(%"));
Use php's crypt library. Md5 is not encryption, it is hashing.
Also, salt your passwords. Why?
This answer
Another good answer
First, you should create a random user salt. Then you should store that and the password hash in the database.
$salt = md5(unique_id().mt_rand().microtime());
$pass = sha1($salt.$_REQUEST['pass']);
and save the $salt and $pass in the database. Then when they go to login you look up their row and check the hash:
$user = query('SELECT * FROM `user` WHERE username = ?', array($_REQUEST['username']));
if($user)
{
// If the password they give maches
if($user->pass === sha1($user->salt. $_REQUEST['pass']))
{
// login
}
else
{
// bad password
}
}
else
{
// user not found
}
Creating a user salt for each account insures rainbow tables are useless and anyone that broken into your server would have to brute-force each password.
Use crypt with some salt. Such as
$user = strip_tags(substr($_REQUEST['user'],0,32));
$plain_pw = strip_tags(substr($_REQUEST['pass'],0,32));
$password = crypt(md5($plain_pw),md5($user));
as on http://www.ibm.com/developerworks/opensource/library/os-php-encrypt/
Most basic: Hash it with MD5 or SHA1
$newpass = md5($_REQUEST['pass']);
or
$newpass = sha1($_REQUEST['pass']);
Recently I started storing the username hashed as well, so login attempts are secure using only hashed data for comparisons.
You can "salt" the hashes with extra data so if they are compromised, it's value cannot be found (try googling some simple hashed words).. i.e. use a site-wide string just to alter the standard hash like md5("mySiteSalt!!" . $_REQUEST['pass']); or something more advanced.
You should use SHA1 to hash your passwords for storage in the database. It's the simplest, yet most effective way to store passwords:
$password = sha1($password);
It's also exceptionally safe. Though the integrity of it is beginning to creep, it's rather easy to upgrade this function to SHA-256 (which is incredibly secure).
To find out why md5, sha1 and their speedy friends might not be a good idea, you should read the post Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes by Thomas Ptacek. The gist:
Finally, we learned that if we want to
store passwords securely we have three
reasonable options: PHK’s MD5 scheme,
Provos-Maziere’s Bcrypt scheme, and
SRP. We learned that the correct
choice is Bcrypt.
Note: it's PHK, not php.
I'm using the Auth Module in Kohana v 2.3.4.
In terms of authenticating users, there's a two step process. The entry point is the function login. It's first task is to retrieve the password stored in the database and retrieve the password and determine the salt value. The salt is supposedly determined by an array of values, each corresponding to a point in the $salt.$password hashed value to introduce yet another part of the salt. In my case, I'm using md5.
Problems:
I can't find a configuration for this SALT value. It seems to be relying on one already present within the password stored in the database. Is there one or do I need to configure AUTH to do so since this login needs to be portable and reproducible? If it can't detect the salt, in the hash_password routine, it defaults to using uniqid(), which I don't believe is portable at all.
In terms of adding users, does it make sense to modify the Auth library to add this feature? ie, introduce my own customized SALT that I can say, do an MD5 hash on that and then use that md5 generated by the salt to seed the password at given points in the md5sum?
I'm no security expert, but is this overkill? Granted, it prevents someone who were to get access to the md5 password list from using a md5 lookup of predetermined hashes.
If you have used the Kohana PHP framework, if you have any lessons learned or experiences after using it that might give insight as to the right approach for this problem, let me know. I'm reading numerous forums and wiki's about it, and there isn't a real concrete opinion yet that I've seen. I'm essentially trying to get a reproducible approach for authenticating someone in this site, both using PHP and eventually from a mobile device, like an iPhone. I'm also thinking of eventually adding support for google friend connect for openID support and integration.
Below are snippets from the Auth module in Kohana concerning the functions of interest. They have some debugging in them as I'm trying to better understand what's going on.
public function login($username, $password, $remember = FALSE)
{
if (empty($password))
return FALSE;
if (is_string($password))
{
// Get the salt from the stored password
$salt = $this->find_salt($this->driver->password($username));
Kohana::log('debug', "--- Auth_Core login salt = $salt ");
Kohana::log('debug', "--- Auth_Core login pass = $password ");
// Create a hashed password using the salt from the stored password
$password = $this->hash_password($password, $salt);
}
Kohana::log('debug', "--- Auth_Core login pass_hash = $password ");
return $this->driver->login($username, $password, $remember);
}
public function find_salt($password)
{
$salt = '';
foreach ($this->config['salt_pattern'] as $i => $offset)
{
// Find salt characters, take a good long look...
//$salt .= $password[$offset + $i];
$salt .= substr($password, $offset + $i, 0);
}
return $salt;
}
public function hash_password($password, $salt = FALSE)
{
Kohana::log('debug', "--- Auth_Core Original Pass = $password ");
if ($salt === FALSE)
{
// Create a salt seed, same length as the number of offsets in the pattern
$salt = substr($this->hash(uniqid(NULL, TRUE)), 0, count($this->config['salt_pattern']));
Kohana::log('debug', "--- Auth_Core salt created = $salt ");
}
// Password hash that the salt will be inserted into
$hash = $this->hash($salt.$password);
// Change salt to an array
$salt = str_split($salt, 1);
// Returned password
$password = '';
// Used to calculate the length of splits
$last_offset = 0;
foreach ($this->config['salt_pattern'] as $offset)
{
// Split a new part of the hash off
$part = substr($hash, 0, $offset - $last_offset);
// Cut the current part out of the hash
$hash = substr($hash, $offset - $last_offset);
// Add the part to the password, appending the salt character
$password .= $part.array_shift($salt);
// Set the last offset to the current offset
$last_offset = $offset;
}
Kohana::log('debug', "--- Auth_Core hashpw = $password + $hash ");
// Return the password, with the remaining hash appended
return $password.$hash;
}
Problem 1. The salt configuration is stored in config/auth.php. Find that file in modules/auth/config, then in your app/config folder (as you might have already known, Kohana uses cascading file system mechanism). The default file, which you are encouraged to customize into app/config/ folder, looks like below:
<?php defined('SYSPATH') OR die('No direct access allowed.');
return array
(
'driver' => 'ORM',
'hash_method' => 'sha1',
'salt_pattern' => '1, 3, 5, 9, 14, 15, 20, 21, 28, 30',
'lifetime' => 1209600,
'session_key' => 'auth_user',
'users' => array
(
// 'admin' => 'b3154acf3a344170077d11bdb5fff31532f679a1919e716a02',
),
);
Problem 2. In my opinion, the password hashing mechanism used by Auth, which is SHA1 with salt insertion, is quite secure provided you keep your salts, i.e. your auth.php file, secure.
Problem 3. Auth built-in hashing mechanism uses SHA1, which is relatively more crack-proof than MD5, so I would say don't do the MD5 way, no matter how complicated your scheme might look. A security expert Thomas Ptacek in his blog wrote:
No, really. Use someone else’s
password system. Don’t build your own.
Most of the industry’s worst security
problems (like the famously bad LANMAN
hash) happened because smart
developers approached security code
the same way they did the rest of
their code.
Problem 4. Yup I'm using Kohana to build my small company website and some of our clients' website and so far I don't find any problem with the Auth module, although I can't say much since I haven't really used it for real security-concerned website. But in general, I'd say Kohana is an excellent framework especially with the cascading filesystem mechanism.
Regarding point 1, the hash_password() function is used both to generate the password hash (against the salt and including the salt) that is stored in the database (e.g. at signup-time), as well as to recreate that hash when the password needs to be verified (e.g. at login-time). The hash_password() function will encode any salt that is given (or uniqid() if none is given) in the password-hash itself; that's a form of encryption where the salt_pattern is the key; if the salt_pattern can be kept secret, then that provides additional security since an adversary will not be able to do offline brute-forcing of the hash since the method of hashing is not reproducible (if the salt_pattern can be kept secret):
// Signup time; forget about uniqid(); you can use any salt that
// you please; once the password hash is stored in the database there
// is no need to know where your salt came from since it will be
// included in the password hash.
$password_hash = hash_password($password, FALSE);
// Login time; note that the salt is taken from the password hash itself.
$reproduced = hash_password($password, find_salt($password_hash));
$verifies = $password_hash == $reproduced;
The hash_password() function will first hash the password against the salt, and then insert each char of the salt into the password hash at the corresponding salt_pattern offset. find_salt() will extract these salt chars so that the hash can be reproduced. You can see it as hash_password() encrypting the salt and find_salt() decrypting it. Although you can also see it has hash_password() hiding the salt and find_salt() finding it, this method of encryption can't be called steganography, I think, because it is clear from the code that there is a salt stored with the password hash (the existence of the salt is not secret).
Regarding point 2, using your own salt is straightforward and fully compatible with the Auth module and an already existing database.
Regarding point 3, using a per user salt (uniqid() by default) is not overkill. Especially with MD5 which is broken for security purposes and where finding collisions is already practical with today's technology. Even better would be to use bcrypt() which uses a purposefully slower hashing algorithm to thwart brute-forcing attempts.
Regarding point 4, I haven't used the Kohana framework before, but reproducing or porting the Auth module is straightforward. Care must be taken that the salt_pattern is not forgotten or lost since it is an essential part of the hashing algorithm. The salt_pattern should also be kept secret since it is the only thing that keeps a determined adversary from brute-forcing the password hashes. uniqid() is just a reasonable default and can be replaced with whatever you want (as long as it is per-user and not a constant site-wide value.)
Also, there is a very good answer here on stackoverflow regarding portable bcrypt() and PHP. Naturally that will not be compatible with the Auth module, but I'd like to mention it anyway since it's just best practice to use a slow hash and not to rely on secrets that are difficult to keep, like the salt_patten.