This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Secure hash and salt for PHP passwords
THREE part question:
Which technique I should use to store a password? (sha1, sha256/512, etc.)
What is the ideal size of a salt?
What should i use ?
$passwordHash = hash('ENCRYPTION',$salt . $password);
or
$passwordHash = hash('ENCRYPTION',$password . $salt);
I intend to store forum passwords only. I am not storing bank credentials or any other highly sensitive items. It should be fast and not rocket science.
I used MD5 but since it is known that it is broken, I now use SHA-2
$hash = hash('sha256', $pass); - creates 256 bit hash.
Personally, I'd still go with MD5 - it's very fast and widely implemented.
Although security researchers have found a way to make two blocks of text that result in the same MD5 hash (a "collision attack"), there's no known practical way to create an a block of text that produces a specific hash (a "pre-image attack")
Just make sure that you do have a decent length salt (16 random bytes should be more than enough) to ensure that a hacker can't use "rainbow tables" to reverse your hashes.
In my opinion, you should use SHA512, if availble, as it is one of the strongest hashing algorithms that are availble at the moment.
Regarding salt sizes, I would use one the same size as the hash, as the adds a lot more entropy to the hash. I use the uniqid() function in conjunction with the rand() function
I would use code similar to what is below
<?php
$password = 'password';
//Generate the salt
$salt = hash('sha512',uniqid('',true) . rand());
//Hash our password with the salt
$passwordHash = hash('sha512',$salt . $password);
?>
Any as you state -- it`s not so highly sensitive
Any, but if you want precise number, let it be 32
Any, as the main purpose of the salt is don`t give bad man to determine, whether two passwords are same.
For example I`m a developer of some system and decide to store only login-n-password hash:
user1:qjwhegwqe7865weq786ew7q8
user2:kl21j3kl21j3kl21j3kl12jk
user3:qjwhegwqe7865weq786ew7q8
As you can see, without salt bad man will see, that user1 and user3 have same passwords. That's why salt was invented -- it creates always different hashes. And it's only one it's purpose.
Related
This question already has answers here:
Best way to store password in database [closed]
(8 answers)
Closed 10 years ago.
Yes I know storing passwords in plain text is not advised.Is there a best and easy way to store passwords so that the application remains secure ??
First off, md5 and sha1 have been proven to be vulnerable to collision attacks and can be rainbow tabled easily (when they see if you hash is the same in their database of common passwords).
There are currently two things that are secure enough for passwords that you can use.
The first is sha512. sha512 is a sub-version of SHA2. SHA2 has not yet been proven to be vulnerable to collision attacks and sha512 will generate a 512-bit hash. Here is an example of
how to use sha512:
<?php
hash('sha512',$password);
The other option is called bcrypt. bcrypt is famous for its secure hashes. It's probably the most secure one out there and most customizable one too.
Before you want to start using bcrypt you need to check if your sever has it enabled, Enter
this code:
<?php
if (defined("CRYPT_BLOWFISH") && CRYPT_BLOWFISH) {
echo "CRYPT_BLOWFISH is enabled!";
}else {
echo "CRYPT_BLOWFISH is not available";
}
If it returns that it is enabled then the next step is easy, All you need to do to bcrypt a password is (note: for more customizability you need to see this How do you use bcrypt for hashing passwords in PHP?):
crypt($password, $salt);
A salt is usually a random string that you add at the end of all your passwords when you hash them. Using a salt means if someone gets your database, they can not check the hashes for common passwords. Checking the database is called using a rainbow table. You should always use a salt when hashing!
Here are my proofs for the SHA1 and MD5 collision attack vulnerabilities:
http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html, http://eprint.iacr.org/2010/413.pdf, http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf, http://conf.isi.qut.edu.au/auscert/proceedings/2006/gauravaram06collision.pdf and Understanding sha-1 collision weakness
Hashing algorithms such as sha1 and md5 are not suitable for password storing. They are designed to be very efficient. This means that brute forcing is very fast. Even if a hacker obtains a copy of your hashed passwords, it is pretty fast to brute force it. If you use a salt, it makes rainbow tables less effective, but does nothing against brute force. Using a slower algorithm makes brute force ineffective. For instance, the bcrypt algorithm can be made as slow as you wish (just change the work factor), and it uses salts internally to protect against rainbow tables. I would go with such an approach or similar (e.g. scrypt or PBKDF2) if I were you.
Store a unique salt for the user (generated from username + email for example), and store a password. On login, get the salt from database and hash salt + password.Use bcrypt to hash the passwords.
Passwords in the database should be stored encrypted.
One way encryption (hashing) is recommended, such as SHA2, SHA2, WHIRLPOOL, bcrypt
DELETED: MD5 or SHA1. (those are older, vulnerable
In addition to that you can use additional per-user generated random string - 'salt':
$salt = MD5($this->createSalt());
$Password = SHA2($postData['Password'] . $salt);
createSalt() in this case is a function that generates a string from random characters.
EDIT:
or if you want more security, you can even add 2 salts:
$salt1 . $pass . $salt2
Another security measure you can take is user inactivation: after 5 (or any other number) incorrect login attempts user is blocked for x minutes (15 mins lets say).
It should minimize success of brute force attacks.
best to use crypt for password storing in DB
example code :
$crypted_pass = crypt($password);
//$pass_from_login is the user entered password
//$crypted_pass is the encryption
if(crypt($pass_from_login,$crypted_pass)) == $crypted_pass)
{
echo("hello user!")
}
documentation :
http://www.php.net/manual/en/function.crypt.php
You should use one way encryption (which is a way to encrypt a value so that is very hard to revers it). I'm not familiar with MySQL, but a quick search shows that it has a password() function that does exactly this kind of encryption. In the DB you will store the encrypted value and when the user wants to authenticate you take the password he provided, you encrypt it using the same algorithm/function and then you check that the value is the same with the password stored in the database for that user. This assumes that the communication between the browser and your server is secure, namely that you use https.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Secure hash and salt for PHP passwords
WARNING Don't use MD5 for passwords, use an alternative like bcrypt
For my passwords should I use salt like this (the salt will be unique to each user and not stored directly with the password)...
$salt = sha1(md5("coders gonna code"));
$password = md5($salt.$password);
or would it be okay if I just used:
$password = md5($password);
because if I used salt, even if the user makes up a bad password like password it won't matter because the salt (in this case) would be 145ac26ff093c6e1317f7d5fb4c9fd11c77be975 so the entry for there password would be 145ac26ff093c6e1317f7d5fb4c9fd11c77be975password which according to http://howsecureismypassword.net/ it would take 3 octodecillion years to crack.... so opinions? Or should I be even worse and go
$password = md5($salt.$password.md5($salt));
If the person has gone far enough to get the salt hash, would anything be able to stop then going futher? < More of a statement this last password
To everyone who said I should do it per user... I know, this is just an example.
You should change the salt so that it is specific to each user, not a system wide constant. This will make rainbow table attacks against your password hashes much more inconvenient.
There is a good write up on the evolution of salting in this article by Troy Hunt.
Edit
$salt something unique to each password record, which adds much entropy to it. This is usually a random sequence of bytes, stored with the user account.
Hashing is traditionally done on the concatenation of salt + password.
$passwordHash = hash($salt.$password);
As others have said, don't use MD5 for hashing. It is broken.
Applying additional proprietary algorithms to password or salt prior to hashing is not recommended. Instead, look at an industry strength solution such as PBKDF2, which, in addition to salting, also requires many (typically > 10k) repeated iterations which will further slow down an attacker.
If you adopt OWASP guidelines, the number of hashes performed should be increased regularly (to counteract Moore's Law). The number of hashes should also be persisted per user, meaning you will need to store the triple of hashed password, salt, and number of iterations.
You are using the salt totally incorrectly. Salts should be unpredictable; your salt is the exact opposite of that (fixed). Since a fixed hash is of absolutely no benefit, it also seems that you are counting on the salt not being known by the attacker. This is the definition of security through obscurity, which is another bad practice.
What you should be doing is:
Use an unpredictable string of reasonable length as the salt. Randomly generated 8-character strings from a pool such as lower/upper case letters and digits are fine.
Use a different salt for each user, and change it every time they change their password.
Move from MD5 (which is considered broken) to another hash function better suited to this application. SHA-1 is better because it's not considered broken; bcrypt is the best because it has a configurable load factor.
Don't use MD5 as your hashing algorithm, use something more secure such as SHA256 or even bcrypt.
Definately salt the password, if someone did gain entry to your database they would not be able to reverse the passwords for common hashes or using techniques such as rainbow attacks.
http://michaelwright.me/php-password-storage
http://en.wikipedia.org/wiki/Bcrypt
First of all you should never store md5 directly, which you regognized already.
PHP 5.5 will bring new methods to easily create and verify passwords in 1 line, until then you can use https://github.com/ircmaxell/password_compat (forward-compatible) to generate & verify safe password hashes.
I think salt is understood here incorrectly. The idea of salt is that it should be unique per hash. The reason is that when you create hash some different strings may have the same hash.
In your example you're hashing password too so it won't look like: 145ac26ff093c6e1317f7d5fb4c9fd11c77be975password
P.S. Use bcrypt. It's much more reliable.
Salts are meant to be completely random, and unrelated to the actual password you are storing a hash of.
What you should really do is generate a completely random salt, then do
$password = md5($salt.$password);
and store the user's username, salt and hashed password.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to best store user information and user login and password
How do you use bcrypt for hashing passwords in PHP?
I am used to using the md5() which I know is now outdated and I hear that sha1() is also insecure. So what is exactly the best way to store and retrieve passwords in a database these days with security in mind? I'd be very happy if you can provide a small example.
Thank you!
I would recommend looking at bcrypt, since it can help against brute-force attacks. http://codahale.com/how-to-safely-store-a-password/
You can find example Here
You should really use bcrypt to hash your passwords, it was designed especially for hashing password.
Hash functions for passwords should be slow (need some computing time). Most hash algorithms like SHA-1 and MD5 or even SHA-256 are designed to be fast, but this makes it an easy target for brute force attacks. An off-the-shelf GPU is able to calculate about 8 Giga MD5 hashes per second!
Don't be afraid to use bcrypt! It is not for high security sites only, and using it can be as easy, as using an md5 hash. It's recommended to use a well established library like phpass, and if you want to understand how it can be implemented, you can read this article, where i tried to explain the most important points.
UPDATE:
Current PHP versions offers the functions password_hash() and password_verify() to handle passwords. Use them like this:
// 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);
We use crypt with Blowfish:
// Hash our password
$hashed = crypt($plain_text_password, '$2a$08$' . substr(hash('whirlpool', microtime()), rand(0, 105), 22));
// Validate a password
if (crypt($plain_text_password, $hashed) == $hashed)) {
// Valid password
}
The salt prefix $2a$ (read the docs) is what instructs crypt to use Blowfish. And assuming the implementation of crypt(3) in the underlying OS supports it, you get it "for free."
md5\sha1 + unique salt = best way
Don't be paranoid.
You could look up alot of encryption codes or mix them for example like this:
sha1(md5(sha1($pw)));
I find that unnecessary so what I use is SHA512 hash("sha512",$pw);
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm trying to find the best way to secure user passwords in a mysql database (hashing/encryption wise). I was which method was the most secure and hardest to crack. I am not very experience in the realm of encryption/hashing etc. Currently I am using a very unsecure method of doing this sort of encryption:
$encrypted_password = strrev(base64_encode($password));
I know that isn't the best way to do it, but like I said, I'm new. Could anyone point my in the right direction?
Thanks.
Use bcrypt:
Bcrypt is an adaptive password hashing algorithm which uses the Blowfish keying schedule, not a symmetric encryption algorithm.
Read the accepted answer here:
openssl_digest vs hash vs hash_hmac? Difference between SALT & HMAC?
How To Safely Store A Password
Edit: You should take a look at hash_hmac(). I think it's a better approach than just salting.
You can use sha1 and a salt:
$salt = "some random string";
$encrypted_password = sha1($salt.$password);
You add the salt to make it harder to use rainbow tables in case somebody manages to get the encrypted password list.
You could use any one-way hashing method (I just like sha1), but it's always better to salt it before hashing.
use hash_hmac to store encrypted passwords
If you need clear text password, use des/aes/3des
Here is an article from Php.net that talks about "Safe Password Hashing".
From the article:
When hashing passwords, the two most important considerations are the computational expense, and the salt. The more computationally expensive the hashing algorithm, the longer it will take to brute force its output.
There are two functions that are bundled with PHP that can perform hashing using a specified algorithm.
The first hashing function is crypt(), which natively supports several hashing algorithms. When using this function, you are guaranteed that the algorithm you select is available, as PHP contains native implementations of each supported algorithm, in case one or more are not supported by your system.
The second hashing function is hash(), which supports many more algorithms and variants than crypt(), but does not support some algorithms that crypt() does. The Hash extension is bundled with PHP, but can be disabled during compile-time, so it is not guaranteed to be available, while crypt() is, being in the PHP core.
The suggested algorithm to use when hashing passwords is Blowfish, as it is significantly more computationally expensive than MD5 or SHA1, while still being scalable.
You should look at php's hash() function: http://se2.php.net/manual/en/function.hash.php
With this you can use lots of different hash algorithms, I usually go with sha256, and add a salt to it before hashing it.
Passwords should be hashed, not encrypted. That is, you should not be able to decrpyt the password. Instead, you should compare hashes.
User sets password $password = 'hX4)1z'
You get hash of password and store to DB:
$pw = hash_hmac('sha512', 'salt' . $password, $_SERVER['site_key']);
mysql_query('INSERT INTO passwords (pw) VALUES ('$pw');
Customer comes back later. They put in their password, and you compare it:
mysql_query('SELECT pw FROM passwords WHERE user_id = ?'); //$pw = fetch
if ($pw == hash_hmac('sha512', 'salt' . $_REQUEST['password'], $_SERVER['site_key']) {
echo "Logged in";
}
I suggest using SHA2 with a salt to store your password.
To create a SHA2 hash, use this:
$hash = hash("sha512", $password.$salt);
A salt contains some extra characters to add to your password before hashing to prevent rainbow tables (databases of passwords and it's hashes). You can create one using a unique user info (like a user_id) or just create a random one and store it somewhere. Just make sure the salt is long enough.
normally it is better not to encrypt a password, but to hash it.
the difference is that encryption is encoding a string, leaving the possibility to decode it.
hashing is "one-way" - once you "hash" something, you cannot de-hash it. some strings can be hashed into the same result, but good hashing reduces the chance of a collision.
It is best to avoid storing actual passwords, since people tend to use a single common password to multiple websites. this means that you can access their accounts on other websites (or if you are leaked, the hacker can).
it's common to hash the password string together with "salt". This is some random string that it difficult to guess, like &%P)##M##)+!#~!#4320`2##!$0 or something of that sort. Common hash methods are md5/sha1 (or other sha method).
so you would have:
$password = '....';
$enc_pass = sha1( '%^$sd%MDdF)#I#)3asd3223##4*^&(*&##' . $password );
$enc_pass will be stored in the database, and after a login form, the result will be hashed (as above) and compared to the value in the database.
PS: don't forget to have your database column of a size that would contain the entire password ;)
I'd just like to add that storing a hash of the passwords does not automatically make the authentication process secure. What you also should employ is a decent password policy. The reason is, even if you have the most sophisticated hash algorithm of all time, and a user uses the password "password" or "1234", then the algorithm is useless, because the password can be simply guessed.
Don't forget to make a restriction on password strength.
Because password strength is a weakest part of the whole thing.
As long as your users do use weak passwords, no salt nor extra-secure hashing routine would be of any help.
The best hashing algorithm you can use is salted MD5 hashing where you insert some random characters inside the MD5 hashed string for that particular object. But you must remember the positions where you had inserted the random characters. This is required so that you can decrypt the hashing to obtain the original object or string.
$random="abcd";
$hashed=md5(your_string);
$salted_hash=$hashed.$random;
This is the simplest example where I have just concatenated the hashed and salt. but you can insert the salt string somewhere in the middle.
Is the following a good way to salt passwords?
hash('sha256', $_POST['password'], $_POST['email'])
I am using the user email as a salt. Some people do not use emails, some others say to use a random number.
Even if I use a random number then I will still need to store it on my MySQL table, so the salt will still be known anyway, and with the added benefit of using emails is that the possibility of rainbow tables is greatly decreased, even if I was to use a 16-bit integer?
The idea behind a salt is to prevent a hacker from using a rainbow table. For instance, if the hacker is able to compromise your database and figure out what the hashed password is he can't easily reverse engineer the hash to find a value that would generate the same hash.
However, there exist tables of already hashed words called rainbow tables. Some people have already gone through the trouble of calculating the hash of every word in the dictionary and other common passwords. If the hacker has one of these tables, plus the hashed password from your database, it makes it very easy to figure out what the password is.
However, a salt changes all that because now, instead of hashing the password, you are hashing the password plus some random value which means that the rainbow table is now useless. It does not matter if the hacker can compromise the salt.
It is perfectly fine to save the salt in clear text. You want to use something that is not uniform across all users either because, again, that defeats the purpose. I personally like to use the timestamp the account was created.
Does that make sense?
What happens if a user changes his email address? You won't be able to verify his/her password anymore because the salt value will be gone.
You shouldn't use anything as a salt that is likely to change over time. Generate a random salt (long enough to defeat rainbow tables) and use it together with the password to generate the hash.
Right now the best possible solution to use in PHP for password hashing is to use the bcrypt (blowfish) implementation. Why? There are several reasons:
variable 'work' parameter
built-in salt
Keep in mind that if you are not running php 5.3, then crypt_blowfish may not be available on your system.
Work Parameter
Blowfish/crypt is already has an expensive setup time but by setting the work factor you can increase the amount of time it takes to calculate a hash. In addition, you could easily change that work factor in the future as computers get faster and are able to compute hashes more easily. This makes the particular hashing method scale.
Built-in Salt
For me this is just laziness but I like that the salt & pass are stored together.
Implementation
To use blowfish you'd create a hash as follows
// salts must be 22 characters
$salt = "ejv8f0w34903mfsklviwos";
// work factor: 04-31 (string), each increase doubles the processing time.
// 12 takes my current home computer about .3 sec to hash a short string
$work = '12';
// $2a$ tells php to use blowfish
// you end up with a string like '$2a$12$mysalthere22charslong'
$options = '$2a$' . $work . '$' . $salt;
$hashedPass = crypt($plaintext, $options);
To verify a hashed password is simplicity:
if(crypt($user_input, $stored_password) == $stored_password) { echo "valid!"; }
Now, if at any given time you want to increase the work factor you could take the submitted pass after a successfull login, and rehash and save it. Because the work factor is saved along with the salt & password, the change is transparent to the rest of the system.
Edit
There seems to be some confusion in the comments about blowfish being a two way encryption cypher. It is not implemented as such in crypt. bcrypt is an adaptive password hashing algorithm which uses the Blowfish keying schedule, not a symmetric encryption algorithm.
you can read all about it here: http://www.usenix.org/events/usenix99/provos.html
or you can read even more about using bcrypt (the hashing implementation of blowfish) here: http://codahale.com/how-to-safely-store-a-password/
i suggest using iteration such as below. The crypt could be replaced with md5 or any other hashing algorithm. the 10 could be any number.
$pass=mysql_real_escape_string($_POST['pass']);
$iterations = 10;
$hash = crypt($pass,$salt);
for ($i = 0; $i < $iterations; ++$i)
{
$password = crypt($hash . $pass,$salt);
}
In addition, you could add any other variable. I hope this solve the problem
You could use this:
$salt='whatever';
$a=hash('sha256', $_POST['password'], $salt);
$b=hash('sha256', $_POST['email'], $salt);
$hash=$a.'-'.$b;
When the user changes the email, just do:
$old_a=substr($old_hash,0,strpos($old_hash,'-'));
$new_b=hash('sha256', $_POST['email'], $salt);
$new_hash=$old_a.'-'.$new_b;