This question already has answers here:
Double password_hash php
(2 answers)
Closed 5 years ago.
If I hash for example a password twice:
$psw1= password_hash($password,PASSWORD_DEFAULT);
$psw2=password_hash($psw1,PASSWORD_DEFAULT);
Is this more secure or it this just useless?
P.S.: I am new to php
This will prevent you from verifying the password, since you won't be able to reproduce the first hash, since you've discarded the random salt of the first hash. Instead, to increase security of a single hash, simply adjust its cost factor:
password_hash($password, PASSWORD_DEFAULT, ['cost' => 12])
The higher the cost, the more rounds of hashing will be done. Pick a cost that doesn't slow the process down too much, but isn't too low either. In fact, you should keep increasing the cost factor over time as better server hardware becomes available, and rehash your users passwords over time with the stronger algorithm. That's specifically what password_needs_rehash is for.
I think is useless since once hashed it's impossible to know what the real value was...at least teorically speaking.
I suggest using strong hash functions like sha512 or ripemd320 since there are not much publicy available databases where hashed passwords are stored.
If you want to know more I've found an old question on stackoverflow with good answers : PHP dehashing the password
Related
This question already has answers here:
Secure hash and salt for PHP passwords
(14 answers)
Closed 8 years ago.
I was wondering if
password_hash("custompassgoeshere", PASSWORD_BCRYPT)
Is secure enough in order to store passwords to the DB or if I should add some more SALT in it (I was thinking something like user's username/email/date of birth/etc).
Thanks!
Bcrypt would be secure enough on its own., ensure that you increase the iterations/cost to something high enough (but not too slow for your server). You may need to test a few values to test for acceptable hashing times.
You do not need to salt your passwords, Bcrypt generates unique salts for each hash automatically and stores it with the hash.
See: How can bcrypt have built-in salts?
This question already has answers here:
Secure hash and salt for PHP passwords
(14 answers)
Closed 8 years ago.
Is there an advantage as to where password hash and salt occurs, in PHP vs in a database? It seems having the process occur inside of a database would be the optimal solution; since the web server and the database would only have to exchange the password and not the salt.
It's okay to store the salt in the database. It's an advantage to do so, because you want to use a different random salt per user.
I recommend doing the hashing in the application.
The reason is that if you do the hashing in an SQL expression, and you use query logging on the database server, you might be storing plaintext samples of the user passwords in the query log.
If you're using something better than a simple hash + salt, like PBKDF2, you're going to have to involve PHP at this point AFAIK. So in terms of best location, for me, the best location is in the code because that's where you can do the "best" method of password hashing.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Secure hash and salt for PHP passwords
I use the following code to hash and store passwords:
$salt=uniqid(mt_rand(), false);
hash('sha512',$pass+$salt);
Is it secure in our time? If no, what solution is better?
Is crypt() good for this purpose or it's too old?
To make your hashing harder to brute-force, increase the computation time. sha512 is a cryptographic hashing function and it is optimized for speed. You're only hashing a password once when authenticating a user so don't be afraid to take your time.
Since an attacker will be computing millions of hashes, why not make your hash function take 0.1s per hash? You won't notice any significant speed degradation, but any brute-force attacks will be indefeasible.
That being said, instead of going out and writing your own hash function to do this:
hash = sha512(password)
for i in range(10000):
hash = sha512(hash) + salt
return hash
Use tested solutions like phpass, which uses bcrypt.
Hashing with a salt is good. However, you want to apply the hashing algorithm multiple times (a few hundred is a good ballpark).
"Stretching" the hash function in this way does not make for a stronger hash, but rather slows down brute force attacks.
http://en.wikipedia.org/wiki/Key_stretching#Hash_based_key_stretching
It depends on your use of this, it's not going to be sufficient for storing credit card details or bank details (not that you would hash them!) but it will be more than enough IMO for passwords for a website, especially given you are using a salt and it's the 512 hash.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Is “double hashing” a password less secure than just hashing it once?
So, I was reading an article on securing PHP websites and they recommended hashing a password multiple times, in fact, this is a direct quote from the article:
md4(md4(md5(sha1(md4(md5(sha1(sha1($_POST['password']))))))));
Now, personally, I generally use a salted SHA-256 hash on my passwords, because I thought that MD4 and MD5 were no longer secure and that hashing a password multiple times would just put too much strain on a server for no practical benefit. Is that correct?
The direct quote from the article wouldn't work, as there is no md4() function in PHP. And then it wouldn't make sense still.
Normally applying multiple hashing functions wouldn't hurt. But when you go from sha1 to md5 you are losing input range (md5 gives you 128 bit output, but sha1 is 160 bits long). This is rehashing a shortened excerpt, which means the possible output set is never bigger than that of md5().
If you don't hash your passwords tens of thousands of times, you don't know what you are doing.
This is computationally expensive; that is the point. For the legitimate purpose of authenticating a user who has the correct password, the load is negligible. But for a cracker who is trying to test a huge list of passwords in an offline attack, the cost is prohibitive.
Using thousands of iterations of a hash function is a well-established and widely used technique for "key strengthening." It is incorporated in standards for key derivation, and used in algorithms like bcrypt for password protection.
Use bcrypt or PBKDF2, which will require you to use salt and iterations. Don't try to make up your own method using a few broken hashes.
A bit. If the goal is to actually get the original password, it becomes an impossible task. However, usually it is not, and if you really use md4 for the outermost hash, well.. http://en.wikipedia.org/wiki/MD4#Security
There are many other ways to improve security, the most basic of which is to use some kind of random salt that is not stored along with the password.
This question already has answers here:
Secure hash and salt for PHP passwords
(14 answers)
Closed 10 years ago.
I want to store my passwords using 2 different hashes (saving 2 hashes for the same password to (slightly) increase security by (almost) eliminating collisions.
first question: is there enough of an upside for this in the first place since collisions are negligible anyway ?
second question: what would the best hashes for this be ? do sha-1 and sha-256 have more collisions than sha-256 and some unrelated algorithm like blowfish ?
If I understand you correct you want to store the hashed password two times with two different hashing algorithms in your database yes? Simply use two hashalgorithms producing a different length and there is no chance of collision between the two different hashes at all.
For instance sha1 and md5 provide different lengths of output.
I would recommend using a sha1 and not worrying about collisions. The likelyhood of a sha1 collision is 10^-45 (as explained here Probability of SHA1 collisions), so unless you will have billions of users, it will never be an issue.