This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Secure hash and salt for PHP passwords
Is this a secure way to encrypt the passwords to store in a mysql database:
md5(sha1($password))
Thanks.
What you are doing here is hashing, not encrypting.
Hashing has the purpose of not storing the password itself in the database, so that if the database is stolen the attacker will not gain knowledge of all user passwords.
Hashing should be used in conjunction with salting the hashes, because otherwise it will be relatively easy for an attacker who has gained access to the database to crack the weak passwords stored there.
Also, hashing the same input twice (as your example does with md5 and sha1) does not offer any significant benefit.
Generate random salt for each password and compute password digest with HMAC-SHA1. The salt is used as key and password is used as message. The salt and digest are stored into database.
Related
This question already has answers here:
Secure hash and salt for PHP passwords
(14 answers)
Closed 5 years ago.
In storing passwords in php mysql, can i assume the passwords to be safe if i were to run md5 algorithm again and again and with combination of text replacement and rotation?
No, MD5 is not secure to use to create a password verifier.
With PHP use password_hash and password_verify, the pair are secure and easy to use.
When saving a password verifier just using a hash function is not sufficient and just adding a salt does little to improve the security. Instead use a function such as PBKDF2, Rfc2898DeriveBytes, Argon2, password_hash, Bcrypt or similar functions with about a 100ms duration. Make the attacker spend substantial of time finding passwords by brute force.
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:
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:
PHP 2-way encryption: I need to store passwords that can be retrieved
Lately I'm a little confused reading several tutorials on storing passwords in databases. Most sites say that the best is using a hash and a salt to store the passwords or also store the passwords in two parts or add a general key for all passwords.
I saw several methods with crypt, sha, sha256, md5 and blowfish.
My question is, using crypt function with blowfish is safe or there are better/safer and more effective methods for storing passwords?
Well, apart from the obvious, not storing, hashing etc...
I'd say don't use the regular {MD5, SHA1, SHA256, SHA512, SHA-3, etc} if you can, even if you can salt them. Reasons for this can be found at:
http://codahale.com/how-to-safely-store-a-password
Simply put: use bcrypt
You might want to read up on this topic on
Password hashing, salt and storage of hashed values
http://dustwell.com/how-to-handle-passwords-bcrypt.html
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
what is best possible way of salting and storing salt?
Improve password hashing with a random salt
Assuming that using a correct algorithm for password hashing and generating different salts for each password...
Is it a security risk to store salts separately from password hashes? For ex. in a database table, storing password hashes in one column, and password salts in a separate column?
I saw strategies where the salt is embedded into the password hash itself, by using a specific algorithm. Later on the salt can be extracted from the password hash. Is this more secure?
From everything I have ever read and done, there is nothing wrong with storing the password hash and password salt in separate columns, and that is the most common way to do it.
The basic method for authentication should go something like this:
Retrieve user_id and password_salt using user supplied username or email
Concat user supplied password input with retrieved salt
Use hashing algorithm on combined string
Check created hash against the hash in the database