As php.net states here:
It is not recommended to use this function to secure passwords, due to
the fast nature of this hashing algorithm.
I have used the md5 function since I started programming with PHP, but after researching, it is clear that md5 is discouraged and an alternative should be used.
I am aware of a possible alternative, sha1. Are there any others as well?
What are the benefits of these other ones, and sha1 (excluding higher security)?
And most importantly, can a sha1 hash or any of the other hashing algorithms be replicated in javascript?
I have an md5 plugin in javascript and it is key to some of my secure applications. Therefore, having a hashing algorithm that has a javascript plugin is absolutely essential.
SHA1 and MD5 have pretty much the same weakness: Their collision resistance is broken. So when MD5 is wrong, so is SHA1. Their output is also a bit short. If collision resistance is required, I recommend at least 256 bit hashes. More than 256 bits are rarely necessary.
For normal hashing applications SHA-256 (part of the SHA-2 family) is a good choice. While it's performance isn't too great, nobody has broken its collision resistance so far. You can also go with SHA-3-256, but the library support isn't that great yet.
For password hashing you need a specialized construction, such as scrypt, bcrypt or PBKDF2. Use a unique salt and a sufficient iteration count. Do not use a plain hash, they're too fast.
For MAC(Message Authentication) use a specialized construction, such as HMAC-SHA-256 and not plain SHA-256.
The upcoming WebCryptoAPI will contain functions for most of these operations.
Until it gets deployed, you can use crypto-js which offers both PBKDF2 and SHA-256.
But I'm a bit doubtful about your architecture. Hashing passwords in javascript is rarely the right choice. Standard procedure is using SSL/TLS and sending the plaintext password over it. You cannot achieve security with in browser javascript unless you use TLS.
Yes, there are many other hashing algorithms as well, much stronger than SHA1. Check SHA512, for example: it has 512 bits against, for example, 128 bits for MD5.
Anyway, if you're looking for real safety, you should apply one of the following:
1) "Fixed salt": instead of md5($pass), you use:
$salt="NaCl";
$hash=md5($salt);
2) "Random salt": instead of md5($pass)', you generate a random salt (use the function rand($minValue, $maxValue)) with a great range (say rand(0, pow(10, 100)) and use md5($pass, $salt). Don't forget to store BOTH the hash and the salt!
3) Encryption: you use either a fixed or a random key (see the precedent method), and use it to encrypt the password. I'd really suggest the Blowfish algorithm.
From the page on PHP.net:
<?php
$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$key = "This is a very secret key";
$text = "Meet me at 11 o'clock behind the monument.";
echo strlen($text) . "\n";
$crypttext = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $key, $text, MCRYPT_MODE_ECB, $iv);
echo strlen($crypttext) . "\n";
?>
Implementing SHA512 in JavaScript (without the salt generation) (from the CryptoJS library):
<script src="http://crypto-js.googlecode.com/svn/tags/3.0.2/build/rollups/sha512.js"></script>
<script> var hash = CryptoJS.SHA512("Message"); </script>
Implementing bcrypt in JavaScript: see this example.
Related
Actually I read many post related to the algorithm for use like md5, sha1 and so on. But I am still not sure which one is the secure and the best one to use nowadays. I am beginner with web development and I am asking all of the best programmers around the world to teach and show me. I hope you guys can give me the choice and example for using it. Thank You
Incidentally: How to safely store your users' passwords in 2016.
Your choices are:
Argon2 (requires PHP 7.2 or a PHP extension)
Scrypt (requires PHP extension)
Bcrypt
If you really need to, also feel free to consider PBKDF2.
The old standby: Bcrypt
Given that you're a beginner, you should be writing your password validation like this:
// Creating your hashed password:
$hash = password_hash($userPassword, PASSWORD_DEFAULT);
// Checking a user-supplied password against a stored hash:
if (password_verify($userPassword, $hash)) {
// Login successful.
if (password_needs_rehash($hash, PASSWORD_DEFAULT)) {
// Recalculate a new password_hash() and overwrite the one we stored previously
}
}
Downside to bcrypt:
Passwords over 72 characters are truncated.
Passwords with a NUL byte will truncate.
A stop-gap that works around these limitations is built into Password Lock: It pre-hashes passwords with SHA384 then base64-encodes the raw hash before passing to PHP's password API.
First, create an encryption key and store it outside your document root. (Otherwise, a hacker can just steal the key.)
$newKey = \Defuse\Crypto\Key::createNewRandomKey();
file_put_contents(
'/outside/document/root/enckey.txt',
$newKey->saveToAsciiSafeString()
);
Now, you can use this key in conjunction with your passwords:
$key = Key::loadFromAsciiSafeString(
file_get_contents('/outside/document/root/enckey.txt')
);
// Hashing a password with PasswordLock:
$storeMe = PasswordLock::hashAndEncrypt($_POST['password'], $key);
// Verifying a password with PasswordLock:
if (PasswordLock::decryptAndVerify($_POST['password'], $storeMe, $key)) {
// Success!
}
You can now use Argon2 with password_hash() in PHP 7.2
The new standard: Argon2 (via Libsodium)
Unless you're on PHP 7.2 or higher, you'll need to install libsodium and the PHP extension to use Argon2. Password hashing is one of the features that is not provided by sodium_compat.
// Password hashing:
$hash_str = sodium_crypto_pwhash_str(
$password,
SODIUM_CRYPTO_PWHASH_OPSLIMIT_INTERACTIVE,
SODIUM_CRYPTO_PWHASH_MEMLIMIT_INTERACTIVE
);
// Password verification:
if (sodium_crypto_pwhash_str_verify($hash_str, $password)) {
// recommended: wipe the plaintext password from memory
sodium_memzero($password);
// Password was valid.
} else {
// recommended: wipe the plaintext password from memory
sodium_memzero($password);
// Password was invalid.
}
Intermediate: Scrypt
You'll need the scrypt extension which is available through PECL:
pecl install scrypt
echo "extension=scrypt.so" > /etc/php5/mods-available/scrypt.ini
php5enmod scrypt
Once that's installed, using it is fairly straightforward:
// Hashing:
$hash = \Password::hash($userProvidedPassword);
// Validation:
if (\Password::check($userProvidedPassword, $hash)) {
// Logged in successfully.
}
The only reason to really use scrypt is compatibility; at this point, go with either Argon2 or bcrypt.
Acceptable but not Great: PBKDF2
I highly recommend going with Defuse Security's cross-platform Password Hashing library if you need PBKDF2. (You should consider just using password_*, however!)
$hash = PasswordStorage::create_hash($password);
if (PasswordStorage::verify_password($password, $hash)) {
// Success
}
Any of the above choices are acceptable. Argon2 is probably the most secure, but it's not widely available in PHP yet. Anything absent from this list should be regarded with a healthy dose of skepticism.
Important is, that the algorithm offers a cost factor, which controls the necessary time to calculate a hash. The more time you can invest in calculating a single hash, the more expensive brute-forcing will become (e.g. 100 Giga MD5 per second vs 10 BCrypt per second).
Today recommended algorithms are BCrypt, PBKDF2 and SCrypt. The algorithm BCrypt is supported by PHP, a wrapper function takes care of the generation of a salt and is future proof.
// 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);
I have this code in a PHP page which I am running multiple times. Every time I refresh the page, the salt changes (as it should), but the hash output stays the same.
$iv = mcrypt_create_iv(22);
$ro = rand(6, 9);
$salt = '$2y$'.$ro.'$'.$iv.'$';
echo $salt;
echo '<br />';
$crypt = crypt('test', $salt);
echo $crypt;
Shouldn't the random salt affect the output and make it so that every time I refresh the page the crypt result changes too?
I also have a few general questions on crypt().
Is there any way for you to use a specific hashing algorithm with this function? I would like to use the blowfish algorithm.
Is it the salt length/format that affects which algorithm it chooses?
Lastly, should the salt length for the blowfish algorithm always be 22 characters, or is that just the maximum?
By the way, if anyone is wondering (and if it matters for answering these questions and wasn't obvious), I'm planning to use something similar to store hashed passwords.
Thank you for looking!
The crypt() function on your system does not support the "2y" algorithm. At least Linux GLIBC 2.7 based systems only know DES, $2a$ (blowfish), $5$ (SHA-256) and $6$ (SHA-512). Therefore, the crypt() function assumed DES and only took the first two characters "$2" as salt. That of course produced always the same output.
Try SHA-512 for secure password hashes:
$salt_chars = array_merge(range('A','Z'), range('a','z'), range(0,9));
$salt = '$6$';
for($i=0; $i < 8; $i++) { $salt .= $salt_chars[array_rand($salt_chars)]; }
echo "salt=$salt\n";
$crypt = crypt('test', $salt);
echo "crypt=$crypt\n";
Regarding your second question, you can chose the algorithm by starting the salt with e.g. "$2a$" (instead the $6$ above) for blowfish. Read "man 2 crypt" for details. For some algorithms you can also encode more parameters like "rounds=4000" into the salt.
According the the crypt() manpage, the salt may be up to 16 characters following the $id$.
Longer salts will silently be truncated and produce the same output as for only the first 16 characters.
BTW, even in /etc/shadow, passwords only use 8 characters of salt with the SHA-512 algorithm. As the salt is only to make rainbow table attacks harder, this seems sufficient.
So another stack overflow user recommended the following code to create a hash:
$password = 'my password';
$salt = strtr(base64_encode(openssl_random_pseudo_bytes(18)), '+', '.');
$pwhash = crypt($password, sprintf('$2y$%02d$%s', 13, $salt));
Is there another function for openssl_random_pseudo_bytes if I don't have openssl installed? Does it make sense to install this, and if so, how would I do this?
Try using mcrypt_create_iv(18). Although it is used for generating initialization vectors for encryption it uses /dev/random by default for generating a random vector.
EDIT: http://php.net/manual/en/function.mcrypt-create-iv.php
PHP 5.5 will have it's own functions password_hash() and password_verify() to create BCrypt hashes (that is what your function does). There is a compatibility pack for PHP 5.3/5.4 available, downloadable in form of a single php file password.php.
It is a well done implementation, that uses mcrypt_create_iv, but has a fallback to openssl_random_pseudo_bytes.
mcrypt_create_iv($raw_length, MCRYPT_DEV_URANDOM);
Note that the mcrypt_create_iv function reads from MCRYPT_DEV_URANDOM, that's enough for creating password salts (salt should be unique and unpredictable). In contrast to the default value MCRYPT_DEV_RANDOM it does not block the server, should there be not enough entrophy available.
I am rewriting a PHP Login system and I just faced this
function createSalt()
{
$string = md5(uniqid(rand(), true));
return substr($string, 0, 3);
}
$salt = createSalt();
$hash = hash('sha256', $salt . $hash);
Actualy I never worked with salting before, I searched a bit and found it useful.
But my answer is, Is this a good way to work with salt?
Wouldn't $string = sha1(uniqid(mt_rand(), true)) be better?
And what about returning only 3 characters of the hash? I really don't get it.
What you think?
Consider using PHP's crypt() instead of reinventing the wheel. It is specifically designed for password hashing, and offers hash algorithms suited for that purpose.
I prefer sha1 or sha256, md5 is super-outdated, the sha-functions are way better. But this is my opinion, choose what you want.
What is really important in this case is the salt. A salt is always stored in plaintext together with the hash and is used to improve the length of a password (if you want to hash the password, might be something else of course) to prevent attacks based on rainbow/lookup tables. This is no protection against cracking the password by using bruteforce (which works quite well against md5, so use sha256 which is harder to crack).
Therefore it is totally unimportant if you use 32 random chars for the hash, or something like md5(mt_rand()) - important is the length. I would use something like
$hash = md5(mt_rand()) . md5(mt_rand());
md5() results in 32 bytes string, based on a random number (mt_rand() is better then uniqueid()). With this simpel line you get a very "strong" hash which should secure every password against rainbow tables.
I don't agree with the given function createSalt() - mainly for the same reasons as you.
My approach to this would be
define(SALT_LENGTH,32);
function createSalt()
{
$string='';
for ($i=0;$i<SALT_LENGTH;$i++) $string.=chr(rand(0,255));
return $string;
}
A good salt is a random byte sequence - no MD5 or SHA1 makes any sense, as there is nothing to hash!
I no master PHP programmer but I've been working on the same hash script for a login system.
Im storing it on GitHub - https://github.com/revitalagency/PHP5-Salt-Super-Admin
I created my hash using...
hash_hmac('sha256', $_POST['pass'], GLOBAL_SALT);
GLOBAL_SALT is defined in a config file not in the DB for extra protection.
At the moment I have a database with md5 passwords stored, a few years back this was considered a little more secure than it is now and it's got to the point where the passwords need to be more secure.
I've read a lot of posts on here about crypt, md5, hash, bcrypt, etc and have come to consider using something along the lines of the following to 'secure' the passwords better than they are now.
I will use a combination of hash("sha512" and two salts, the first salt will be a site wide salt stored in a file such as .htaccess and the second salt will be created for each user.
Here's an example along the lines of what I'm testing at the moment:
.htaccess
SetEnv SITEWIDE_SALT NeZa5Edabex?26Y#j5pr7VASpu$8UheVaREj$yA*59t*A$EdRUqer_prazepreTr
example.php
$currentpassword = //get password
$pepper = getenv('SITEWIDE_SALT');
$salt = microtime().ip2long($_SERVER['REMOTE_ADDR']);
$saltpepper = $salt.$pepper;
$password = hash("sha512", md5($currentpassword).$saltpepper);
The salt would obviously need to be stored in a separate table to allow checking of future inserted login passwords but it would never be possible for a user to see. Do you think this is a sufficient way to go about this?
Ok, let's go over a few points here
What you have in $salt is not a salt. It's deterministic (meaning that there is no randomness in there at all). If you want a salt, use either mcrypt_create_iv($size, MCRYPT_DEV_URANDOM) or some other source of actual random entropy. The point is that it should be both unique and random. Note that it doesn't need to be cryptographically secure random... At absolute worst, I'd do something like this:
function getRandomBytes($length) {
$bytes = '';
for ($i = 0; $i < $length; $i++) {
$bytes .= chr(mt_rand(0, 255));
}
return $bytes;
}
As #Anony-Mousse indicated, never feed the output of one hash function into another without re-appending the original data back to it. Instead, use a proper iterative algorithm such as PBKDF2, PHPASS or CRYPT_BLOWFISH ($2a$).
My suggestion would be to use crypt with blowfish, as it's the best available for PHP at this time:
function createBlowfishHash($password) {
$salt = to64(getRandomBytes(16));
$salt = '$2a$10$' . $salt;
$result = crypt($password, $salt);
}
And then verify using a method like this:
function verifyBlowfishHash($password, $hash) {
return $hash == crypt($password, $hash);
}
(note that to64 is a good method defined here). You could also use str_replace('+', '.', base64_encode($salt));...
I'd also suggest you read the following two:
Fundamental difference between hashing and encrypting
Many hash iterations, append salt every time?
Edit: To Answer the Migration Question
Ok, so I realize that my answer did not address the migration aspect of the original question. So here's how I would solve it.
First, build a temporary function to create a new blowfish hash from the original md5 hash, with a random salt and a prefix so that we can detect this later:
function migrateMD5Password($md5Hash) {
$salt = to64(getRandomBytes(16));
$salt = '$2a$10$' . $salt;
$hash = crypt($md5Hash, $salt);
return '$md5' . $hash;
}
Now, run all the existing md5 hashes through this function and save the result in the database. We put our own prefix in so that we can detect the original password and add the additional md5 step. So now we're all migrated.
Next, create another function to verify passwords, and if necessary update the database with a new hash:
function checkAndMigrateHash($password, $hash) {
if (substr($hash, 0, 4) == '$md5') {
// Migrate!
$hash = substr($hash, 4);
if (!verifyBlowfishHash(md5($password), $hash) {
return false;
}
// valid hash, so let's generate a new one
$newHash = createBlowfishHash($password);
saveUpdatedPasswordHash($newHash);
return true;
} else {
return verifyBlowfishHash($password, $hash);
}
}
This is what I would suggest for a few reasons:
It gets the md5() hashes out of your database immediately.
It eventually (next login for each user) updates the hash to a better alternative (one that's well understood).
It's pretty easy to follow in code.
To answer the comments:
A salt doesn't need to be random - I direct you to RFC 2898 - Password Based Cryptography. Namely, Section 4.1. And I quote:
If there is no concern about interactions between multiple uses
of the same key (or a prefix of that key) with the password-
based encryption and authentication techniques supported for a
given password, then the salt may be generated at random and
need not be checked for a particular format by the party
receiving the salt. It should be at least eight octets (64
bits) long.
Additionally,
Note. If a random number generator or pseudorandom generator is not
available, a deterministic alternative for generating the salt (or
the random part of it) is to apply a password-based key derivation
function to the password and the message M to be processed.
A PseudoRandom Generator is available, so why not use it?
Is your solution the same as bcrypt? I can't find much documentation on what bcrypt actually is? - I'll assume that you already read the bcrypt Wikipedia Article, and try to explain it better.
BCrypt is based off the Blowfish block cipher. It takes the key schedule setup algorithm from the cipher, and uses that to hash the passwords. The reason that it is good, is that the setup algorithm for Blowfish is designed to be very expensive (which is part of what makes blowfish so strong of a cypher). The basic process is as follows:
A 18 element array (called P boxes, 32 bits in size) and 4 2-dimensional arrays (called S boxes, each with 256 entries of 8 bits each) are used to setup the schedule by initializing the arrays with predetermined static values. Additionally, a 64 bit state is initialized to all 0's.
The key passed in is XOred with all 18 P boxes in order (rotating the key if it's too short).
The P boxes are then used to encrypt the state that was previously initialized.
The ciphertext produced by step 3 is used to replace P1 and P2 (the first 2 elements of the P array).
Step 3 is repeated, and the result is put in P3 and P4. This continues until P17 and P18 are populated.
That's the key derivation from the Blowfish Cipher. BCrypt modifies that to this:
The 64 bit state is initialized to an encrypted version of the salt.
Same
The P boxes are then used to encrypt the (state xor part of the salt) that was previously initialized.
Same
Same
The resulting setup is then used to encrypt the password 64 times. That's what's returned by BCrypt.
The point is simple: It's a very expensive algorithm that takes a lot of CPU time. That's the real reason that it should be used.
I hope that clears things up.
Implementation of your new, more secure, password storage should use bcrypt or PBKDF2, as that's really the best solution out there right now.
Don't nest things, as you don't get any real security out of this due to collisions as #Anony-Mousse describes.
What you may want to do it implement a "transition routine" where your app transitions users over from the old MD5-based system to the new more secure system as they log in. When a login request comes in, see if the user is in the new, more secure, system. If so, bcrypt/PBKDF2 the password, compare, and you're good to go. If they are not (no one will be at first), check them using the older MD5-based system. If it matches (password is correct), perform the bcrypt/PBKDF2 transformation of the password (since you now have it), store it in the new system, and delete the old MD5 record. Next time they log in, they have an entry in the new system so you're good to go. Once all of the users have logged in once you implement this, you can remove this transition functionality and just authenticate against the new system.
Do not nest md5 inside your sha512 hash. An md5 collision then implies a hash collision in the outer hash, too (because you are hashing the same values!)
The common way of storing passwords is to use a scheme such as
<method><separator><salt><separator><hash>
When validating the password, you read <method> and <salt> from this field, reapply them to the password, and then check that it produces the same <hash>.
Check the crypt functions you have available. On a modern Linux system, crypt should be able to use sha512 password hashing in a sane way: PHP crypt manual. Do not reinvent the wheel, you probably just screw up more badly than md5, unless you are an expert on cryptographic hashing. It will even take care of above scheme: the Linux standard is to use $ as separator, and $6$ is the method ID for sha512, while $2a$ indicates you want to use blowfish. So you can even have multiple hashes in use in your database. md5 hashes are prefixed with $1$<salt>$ (unless you reinvented md5 hashing, then your hashes may be incompatible).
Seriously, reuse the existing crypt function. It is well checked by experts, extensible, and compatible across many applications.
I looked into this subject a while back and found the following link of great use:
Secure hash and salt for PHP passwords
I also use the following to create a random salt:
public static function getRandomString($length = 20) {
$characters = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
$string = '';
for ($i = 0; $i < $length; $i++) {
$string .= substr($characters, (mt_rand() % strlen($characters)), 1);
}
return $string;
}