4

I know that there are more than a dozen questions about this. But I want to know if it would be better to encrypt passwords for a login system with hash methods like sha1, sha512 etc or would it be better to use Mcrypt ciphers for this ?

I know that decrypting after encrypting with hash methods like sha it's impossible, and if encrypting using mcrypt it's possible. But is it safe to use mcrypt since you can also decrypt ?

Roland
  • 9,321
  • 17
  • 79
  • 135
  • 2
    Hashing is not about encryption. Hashing process is one-way and not reversible (at least not by design). Use hashing for passwords, forget encryption because you do not want to "decrypt" those. Go with SHA-256, SHA-512 or Whirlpool. In the future there will be SHA-3 family as well. Also, mix in some salt and a filesystem key kept separate from the database salt. – Tower Feb 05 '12 at 13:13
  • @rFactor - I understand, and I'm already using SHA512 and salt keys as well. And yes, I'm not storing the salt, just the hash of the pass. And what do you mean by filesystem key ? – Roland Feb 05 '12 at 13:18
  • 1
    You can make it even better if you have a single key on the filesystem outside of your document root that is just a binary file, you load its content and hash it along with salt and the password. This means that in order to crack the hash you need both access to the filesystem and the database. – Tower Feb 05 '12 at 13:28
  • You mean the SSL key which you can buy from a certified provider, or where do I get the filesystem key ? – Roland Feb 05 '12 at 13:30
  • SHA512 with a single iteration is a bad choice. Use a slow scheme, such as PBKDF2, bcrypt or scrypt. – CodesInChaos Feb 05 '12 at 13:44
  • @CodeInChaos - What do you mean by a single iteration ? How could I improve that or make a better encryption with SHA512 ? And I've read that bcrypt for example it only works since PHP 5.3, so what about other versions ? – Roland Feb 05 '12 at 14:17
  • @Roland you generate the filesystem key, it's just data. E.g. generate 512 bytes from `openssl_random_pseudo_bytes()` and output it to a file. – Tower Feb 05 '12 at 14:19
  • I think there are third party libraries that implement bcrypt for earlier versions. By single iteration I mean, that you only call the hash function once, which is fast. By using a scheme that calculates the hash of the hash of the hash... you can slow it down. But don't create such a scheme yourself, use an existing implementation. – CodesInChaos Feb 05 '12 at 14:20
  • @CodeInChaos - And could you suggest a good scheme ? Because I'm looking at at least 6 till now, and I don't know which one is better ... Also, keep in mind that I'm only storing the hash of the pass, not any other salt key or anything else, so if the scheme requires to store the salt as well, I cannot use it. I have found this classes till now : https://gist.github.com/1070401 , https://gist.github.com/1053158 and this one http://stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php. – Roland Feb 05 '12 at 14:27
  • bcrypt and PBKDF2 are the most common schemes. And why can't you store the salt with the hash? And system without salt sucks. – CodesInChaos Feb 05 '12 at 14:32
  • Because having the salt along with the hash in the db it's not a wise thing, instead I'm generating the salt each time the credentials are checked based on the username. So there is no need for storing the salt, just the hash. And which bcrypt class would you suggest ? – Roland Feb 05 '12 at 14:34
  • How do you generate the salt? sitename+userid? And I can't recommend any php bcrypt class, because I don't use php. – CodesInChaos Feb 05 '12 at 15:58
  • No, `return (!empty($len)) ? hash('sha512', str_pad($str, (strlen($str) + $len), substr(hash('sha512', $str), $this->round_up(strlen($str) / 3, 0), ($len - strlen($str))), STR_PAD_BOTH)) : hash('sha512', substr($str, $this->round_up(strlen($str) / 3, 0), 16));` and I use the typed pass and something else to create the salt. Oh, ok, because I have found many classes for that I'm not sure which one is better. Anyway, I think my algorithms are OK, the only thing I don't have it's `microtime()`, which I'm not sure how I could implement it in my algorithm. – Roland Feb 05 '12 at 16:02

3 Answers3

4

Passwords must not be recoverable. The point of hashing them is to make sure that if the database is compromised, the attacker can't get access to every password and thus every user's account (and every account on other services where the password has been reused).

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • OK, because for the moment I'm using an complex algorithm to hash passwords. I was asking because I was thinking of an way to decrypt them if needed, but since using hashes it's out of question. Also, the passwords is plain text when passed to the encryption method, I mean it's posted using `$_POST['input']` where that is the actual password, only after that I hash it, is that a problem ? – Roland Feb 05 '12 at 13:16
  • You do not need to decrypt them, ever. If someone loses their password you let them change it to a new one. – Quentin Feb 05 '12 at 13:21
  • If the data gets intercepted on route, then that is one password compromised. If your database gets cracked then that is every password compromised (unless you use a one-way hash). – Quentin Feb 05 '12 at 13:22
  • If you want to protect passwords en-route, then use HTTPS. – Quentin Feb 05 '12 at 13:22
  • I see, so HTTPS basically encrypts on-route inputs. Well, that means that it's nothing I can do to make my login more secure than it already is, the rest of the security depends on the user, if has HTTPS or HTTP. But what if it has an SSL key and a HTTPS domain ? What would change on my side, in the PHP script where I hash passwords for storing into databse, and what about my random generated salt keys ? – Roland Feb 05 '12 at 13:28
  • Nothing. The use of SSL is transparent as far as any server side programming you do is concerned. – Quentin Feb 05 '12 at 13:30
  • I see, thanks for the info, this enlightened me on what hashing and encrypting really means :) – Roland Feb 05 '12 at 13:33
1

For a password storage that you don't need the plaintext passwords lateron you always should use a Hash-Function. That way you can check the passwords, but a potential attacker cannot find out the plain-text passwords (This is relevant when users always use the same password)

TimWolla
  • 31,849
  • 8
  • 63
  • 96
1

Passwords must NOT be recoverable. As such, you need to use hash algorithms. The most popular are MD5 and SHA1. I won't suggest using MD5 because it can be easily attacked and there are many pregenerated hashes. SHA1 is better, but it has some, too. The most secure is SHA256/SHA512 (part of SHA2 family) based on this. Although, the problem with the SHA2 family is that it is very much based on SHA1. It is not yet broken, but it can be broken soon. If you have time, you may port one of the algorithms made for the SHA3 competition or a less known algorithm. If you can install extensions, then the SHA3 competitors already have PHP extensions.

A good table for the security level is at the Wikipedia. And if you have chosen, you should google "collision attack on [algorithm]" and [preimage attack on [algorithm]" to see whether is there an attack (Wikipedia might be outdated).

Also, don't forget to salt. That means that you hash the $string+"Whatever" instead of $string.

Community
  • 1
  • 1
axiomer
  • 2,088
  • 1
  • 17
  • 26
  • Can you tell me where I can find more about SHA3 future algorithms, since from what I understand it has yet to be released ? – Roland Feb 05 '12 at 13:20
  • 1
    There are five algorithms left in the competition. Their list is at http://csrc.nist.gov/groups/ST/hash/sha-3/Round3/submissions_rnd3.html . Click on their name to download the informations about them. This includes the method and the C ports (not the PHP, sadly). – axiomer Feb 05 '12 at 13:21
  • 2
    1) A plain hash is wrong for password hashing. Use bcrypt or PBKDF2 with a salt. 2) SHA-3 offers no advantages for password hashing, so there is no need to wait or look into that. Even md5 isn't much worse than sha-2 for password hashing. The cryptographic break-throughs mainly affect other use-cases, such as integrity checking or signing. – CodesInChaos Feb 05 '12 at 13:43
  • SHA-3 should not be used before it is defined. The only - very temporary - advantage of SHA-3 over MD5 is that there are no commercially available FPGA's yet, and that there might be no rainbow tables for them yet. But that will change very quickly once the right algorithm is choosen. – Maarten Bodewes Feb 05 '12 at 23:23