So I heard md5() and sha1() are both outdated and potentially broken. I've heard that crypt() isn't a viable solution as well.
If that's the case, can anyone point out what are the current up to date cryptography good practices in PHP? I've searched the web but didn't find anything that looked up to date/potential.
Hash plus salt alone is outdated, too, and generally no longer endorsed in password hashing schemes. It's too easy to calculate such hashes in parallel (even with individual per-user salts), a resourceful attacker is most likely able to break such a scheme.
You should use some form of iterative hashing instead. In addition to applying salts to your passwords, such an algorithm artificially slows the entire hashing process down (cryptographic hashes are generally designed to be as fast as possible while upholding a fixed "security margin"). Suitable primitives to reach this goal are generally considered to be the bcrypt, scrypt or PBKDF2 algorithms. See for example this answer for a discussion on how to use bcrypt in PHP.
Related
I'm looking for a password hash standard that is easy to implement on php and c++. I know there is BCrypt but that really isn't that easy to implement on c++. Are there any hash algorithms that are easy to implement on both languages? I'm looking for this because I don't want my myBB forum cracked. They use md5 with salt which isn't really that good.
It doesn't protect me from being cracked. I know that. But if the forum is compromised I want a secure hash so they can't crack the passwords that easily.
Easy answer: Just use libsodium on both ends, then crypto_pwhash_str() in C/C++ and sodium_crypto_pwhash_str() in PHP. This gives you Argon2id, which is better than bcrypt given appropriate cost factors.
Even if it's tempting to "implement" crypto yourself, you're must better off using a standard implementation such as libsodium, libcrypto (part of OpenSSL), etc.
I suggest stronger algorithms such as SHA-256 or Blowfish. Even with MD5 salt it is weaker besides them.
However, whichever algorithm you use, use salt in your inputs. You can use both in php and c ++ effectively and easily.
I want to create a membership site so i want to make the passwords as safe as possible. I can see from reading sites including this one the md5, sh1 encryption are a serious no no. I've seen some other things like bcript, scrypt, sha256, sha512 and PBKDF2. I have found some php scripts implementing these but not really found anything of note to do with the database.
Do i have to create a row containing the salt?
Verifying the password do i have to do something like hash(salt+password) = $hash?
Because i'm not the most experienced at passwords i'm not really sure of the best practices, how when you hash the password + salt what happens then, how the passwords are retrieved...
I think because i dont really understand the logic behind it i'm feeling a little confused about how to go about it.
If you use Bcrypt, Scrypt, or PBKDF2, the salt is part of the hash you get, so no, you don't have to worry about storing it separately. Otherwise (SHA-*), yes — but you shouldn't use those anyways. Bcrypt, Scrypt, and PBKDF2 are actual password-hashing functions.
I'd recommend Bcrypt, since you tagged this php. It's built-in. Scrypt isn't.
A common best practise (see e.g. Linux passwd) is to store the password hashes as
$<algorithm>$<salt>$<hash>
for example this string:
$6$Lxgyf7h6DtkrqwT$0w/BoB6neYjEtdQdUEs3ftnnNguBNTug8.g/9UeMmZ9bN/cDJCE0dj8.4D/8HPN5bMqFPJ4ECnGl5M2iqBmmv/
is a salted SHA-512 (algorithm id 6) password hash salted with Lxgyf7h6DtkrqwT that should be understood by most servers out of the box.
The benefit of this is that you can actually support different algorithms at the same time. So some users may still have e.g. SHA-256 passwords, while for any user changing his password you switch to a more secure algorithm.
A good starting point to read about modular hashing schemes, read this article in Wikipedia on the crypt (Unix) function. The hype around bcrypt (and the misinformation that crypt would equal DES hashing) is indicative of a certain naiveness of PHP developers with respect to password security. bcrypt is not bad (well, it relies on computational complexity instead of stronger algorithms AFAIK, but it certainly seems to beat MD5). But I would advise using something like this scheme which is A) portable, and B) extensible, so that you can at any time smoothly transition to stronger password hashes.
In 99% of programming languages (including PHP), this functionality is available out of the box via the crypt function, by choosing an appropriate salt, starting with $6$ and the appropriate length of salt characters.
And to clean up some of the misinformation systematically spread by bcrypt advocates: this is not using just one round of sha-512, but the default apparently (see http://www.akkadia.org/drepper/sha-crypt.html ) is 5000 rounds of SHA-512. And you can choose to increase the number. So for my understanding the "but bcrypt can be scaled up when needed" claim also holds for crypt-SHA512. In contrast to bcrypt, this should be available on any Linux system using glibc 2.7 onward. bcrypt is an extension only available on some distributions or with some extensions. On Debian and probably Ubuntu you apparently need to install the extension
libpam-unix2 - Blowfish-capable PAM module
I hear md5 is long dated and obselete. What are my alternative options?
Many thanks.
I recommened you to use SHA-2 family. The SHA-2 family of hash functions are the current replacement of SHA-1. The members of SHA-2 are individually referred to as SHA-224, SHA-256, SHA-384, and SHA-512.
For a hash, you basically just want to choose the largest block size possible, and use a salt value to avoid rainbow attacks.
if you need to replace MD5 in an application where using a hash was a bad design choice in the first place, which include many uses in conjunction with password (protection of login information, or generation of a key from a password), then you do not want just to replace MD5; you want to change the design.
Google pbkdf2. There are implementations in PHP out there, and it's a one-stop-shop for complete password protection. If you're just hashing the password and then done with it, md5 is a little worse than sha1, which is a little worse than sha256, etc, but they're all vulnerable to rainbow tables. Make sure you're using proper salting techniques at minimum, and to really do it right you should use an algorithm like pbkdf2, the object of which is to make it computationally intensive to brute force (with a dash of obscurity in there as well, since it requires the attacker to know the number of iterations you're using, not just the algorithm).
I'm rewriting my password hashing function.
It currently uses sha1.
I'm thinking about using sha512.
Am I right to think that sha512 is sha2?
Is this currently the standard for hashing passwords or should I use another hashing algo?
I would suggest using bcrypt to hash passwords.
This site gives some good background on the issue: http://codahale.com/how-to-safely-store-a-password/
SHA-2 uses four different bit sizes:
hash functions with digests that are 224, 256, 384 or 512 bits.
It should suffice to say whether bcrypt or SHA-512 is good enough. And the answer is yes, either algorithm is secure enough that a breach will occur through an implementation flaw, not cryptanalysis.
If you insist on knowing which is "better", SHA-512 has had in-depth by NIST and others. It's good, but flaws have been recognized that, while not exploitable now, have led to the the SHA-3 competition for new hash algorithms. Also, keep in mind that the study of hash algorithms is "newer" than that of ciphers, and cryptographers are still learning about them.
Even though bcrypt as a whole hasn't had as much scrutiny as Blowfish itself, I believe that being based on a cipher with a well-understood structure gives it some inherent security that hash-based authentication lacks.
So, my recommendation of bcrypt stems from the assumptions 1) that SHA-2 family of hash functions has better scrutiny, and 2) that cryptanalytic methods for ciphers are better developed than those for hash functions.
How much stronger would
return sha1($salt.sha1($passwd));
be compared to just:
return sha1($salt.$passwd);
$salt is a per-user string of length 12 consisting of strong random ASCII.
It's exactly twice as strong, because the attacker needs to perform twice as many SHA1 calculations for a brute force attack.
Of course, that is still not exactly impressive. On the other hand, doing the SHA1 5000 times in a loop is practical for authorization, but makes attacks take 5000 times longer - this technique is known as key strengthening. It is, however, really just a poor man's substitute for the adaptible-cost hash algorithms that Jacco mentions.
At first glance, and without strong knowledge in crypto, I'd say it's not stronger at all.
By the way, it's usually advised to use
sha1($login.$salt.$passwd);
so that 2 users with the same password won't have the same hash.
As far as I know there is no difference in strength.
Since it is common practice to prepend the salt to the password hash, the salt is generally known to an attacker. But this does not defeat the purpose of the salt.
It is generally speaking not a a good idead to add the $login/$username to the hash (Vinzz's solution) as it will cause problems if the user changes his or her username. A better solution is to use a random salt.
The used hashing algorithm does make a difference. SHA1 is considered cryptographically broken and should not be used to hash passwords.
Gennerally speaking BCRYPT (a Blowfish based adaptable-cost hashing algorithm) is considdered best to be the practice (CRYPT_BLOWFISH flag for PHP's crypt();)
Other solid options are SHA256 and above.
Edit:
I wrote a longer answer on salting here: stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/