I was told reliably that MD5 PHP encryption is safe enough. However, I Googled for a crack and a Digg item came up with a link to a large database of hashes for MD5, translating them back into normal passwords.

Is MD5 encryption still safe? If you are handling large numbers of passwords to people's accounts on your web site?

Any advice about his would be much appreciated.

Dan

Yes very. These databases needed to have the original word in the first place (it's one way), so complicated passwords tend to not show up.

Here is a little trick I like to use when encrypting stuff:

PHP Code:

<?php
$password = "1234";
$password = md5(base64_encode(crypt(md5(md5(sha1($password))))));
?>

This would return a very complex encryption, which would confuse someone who saw it and tried to decrypt it. You could also use a find and replace to make a more custom encryption (and it could also work 2 ways). For example:

PHP Code:

<?php
$password = md5('1234'); // convert it to numbers and letters...stops bugs.
$patterns[0] = '/a/';
$patterns[1] = '/1/';
$replacements[1] = 'w34e';
$replacements[0] = 'f43t';
$password = preg_replace($patterns, $replacements, $string);
// You could also then do the above example for total piece of mind.
?>

So MD5 is safe to use, to be creative in how you use it. I mainly use MD5 is shorten passwords and stuff.

I mainly use MD5 for storing stuff that only needs to go one way (like passwords) in databases. If you are handling a large number of passwords and information MD5'ing the stuff the only needs to go one way would be useful as it would:
- Save space (in theory)
- Protect clients information from hackers (if you encrypt something well enough...in theory).

I best point out, nothing is secure, if someone did have the time they could figure out an encryption, for example by putting various words in and finding out the encryption.

Originally Posted by whym

I was told reliably that MD5 PHP encryption is safe enough. However, I Googled for a crack and a Digg item came up with a link to a large database of hashes for MD5, translating them back into normal passwords.

Is MD5 encryption still safe? If you are handling large numbers of passwords to people's accounts on your web site?

Any advice about his would be much appreciated.

Technically it's not encryption, because encryption implies that there is a method for decryption. MD5 was designed to be one-way, and it is, but there is at least one non-brute force algorithm out there which can break it (Google for MD5 collision.)

Currently a very common way to break an MD5 hash is with rainbow tables, which may have been what you found. The simplest defense against this is to salt your passwords. That is,

PHP Code:

$salt = '7hiU,S*&1qs/s'; // arbitrary string of random characters
$password = md5($password.$salt); 


You can also do what rogem did, and hash your hash multiple times with multiple hashing algorithms, which is a good practice as well.

I have been using the SHA-256, SHA-384, SHA-512 hashes (which are more secure than md5 or sha1) in conjunction with salting for my sites' user passwords, but you need PHP 5 to implement these easily.

Ah, I forgot about salting

Rainbow tables tend to cover basic words/passwords (animals, phrases, words etc) but nothing complex.

OK guys thanks a lot for the information. I'll definitely keep all this in mind. The salt method looks the easiest and I'll probably use this.

Thanks again.

No offense, but Rogem's first algo is not a good one to rely on. Encoding something (encrypting or hashing) should not have its security depend upon the method. That is, once one knows that Rogem uses the method just described, it's not hard to reverse engineer it - i.e. a proper collision table.

Encryption is a means of taking a piece of information and writing it in a way which is difficult, but rarely impossible, to reverse back to the original piece of information.

Hashing is a means of taking a piece of information and tweaking it in a fashion that it's virtually impossible to get back the original piece of information. Examples of hashing are MD5 and SHA (1, 256, 512, ...).

Except for one method, all encoding used today relies upon the fact that it's very, very, very hard to break -- but not impossible. If it takes 40 years to decrypt information which is only useful for 4 days, then who will care when it's cracked? If the information is so important that it ought not to be cracked for 100 years then it will matter very much that it's cracked in 40 years.

OK. The pedantic stuff over, let's get to the practical.

1) When hashing: Use a wacky seed like frost demonstrates. Make that seed unique to each program and heavily protect the server that holds the seed. Unless you reset everyone's information that's protected by that seed, you can never change it. Hashing will only work for so long. MD5 was shown to be able to find 2 "phrases" to come to the same code awhile back. Doesn't mean a whole lot from a practical point of view, but you should be using sha1 on PHP 4 servers and the best supported hash for PHP 5 servers (see http://www.php.net/hash for details).

2) Public Key Cryptography is what's currently used to protect most data around. It's based off of the principle that it will take computers a long time to find the 2 prime number factors of a single composite number. Not that it's impossible, just very time consuming. This is what's behind RSA. If you're reading this and wondering, "Is he saying that if I find a way to factor numbers efficiently I will have cracked most of the cryptography in current use?" The answer is yes! Amazing, but true. That's how hard factoring really large numbers can be.

There's a lot of math behind it, but a bit of research on the RSA algo will give you a good start to figuring out how you wish to implement such a methodology.

3) In all of my research there is only one algorithm which when used correctly can guarantee 100% security: The One-Time Pad. It's been around for a while; is fairly easy conceptually; very programmatically heavy; doesn't "support" public-key cryptography; and is still in use today for the most secretive documents of any govt. Remember though: break its rules once and you jeopardize everything you've encrypted. This isn't just some hair-brained idea either: it has been proven (and I can prove it too as the mathematical proof is fairly straight forward) that this method is uncrackable. Try character frequency analysis; word analysis; ... I don't care what you try ... throw as many Crays as you want at it and the text will stay encrypted. It's not used today in day-to-day encryption because there's no known way of deploying it using public-key cryptography. I just love this method so I had to mention it.

When picking a method, use this guide:

Hashing
Use when you don't want the original information discoverable for a period of years. MD5 should not be used as it has been shown to have sufficiently frequent collisions given today's computing power. SHA1 should be used if other more complex algos are not available.

Public-Key Cryptography
Use when you want to be able to find the original information, but want it to be hidden from others for a period of years.

One-Time Pad Encryption
Use for the most sensitive of data that must be recoverable. Time frame is irrelevant given correct implementation. Not appropriate for situations where you cannot safely transmit the decryption key pad to others (e.g. the web).

So therefore I should be using a SHA encryption on my site?

What will I need to do in say a couple of years when encryptions moved on? Will I need all users to reset their passwords?

I would use MD5 over SHA because MD5 allows seeding (I don't think that SHA does).

Either way, while ever you use the wrong terminology you will confuse yourself and others... SHA is not encryption, either: it (just like MD5) is hashing. Therefore assuming that it will be 'entirely safe' (even now) is a silly premise to begin with as it doesn't ensure uniqueness in the first place.

Originally Posted by TwistMyArm

I would use MD5 over SHA because MD5 allows seeding (I don't think that SHA does).

Um, the hashing algo doesn't have anything to do with allowing seeding -- a seed is just something you append or prepend to the string you're hashing.

Originally Posted by whym

So therefore I should be using a SHA encryption on my site?

What will I need to do in say a couple of years when encryptions moved on? Will I need all users to reset their passwords?

The MD5 and SHA hashing functions (just think of them as one-way functions) will be around for quite some time. Choose the best one available and just stick with it. It doesn't hurt to have people occasionally change their passwords either. If you use such a policy then in a few years when new hashes are available, you could switch it around during a password change. Currently on the PHP 5 installs I have access to sha512 is the best available hash and what I use with the hash() function. I wouldn't say to stress too hard on which algo you use unless you're protecting some seriously critical information and then just try to keep up with the latest algo.

To clarify how you would use a hash to allow someone to login, let me offer this example:

PHP Code:

<?php
// Assume $_POST['username'] and $_POST['password'] have been populated by a login form.
// Assume database connection is available via $mysqli object.
// Assume $my_seed is populated with something nice and yucky.
if (strlen($_POST['username']) > 0 && strlen($_POST['password']) > 0) {
  $login_error = false; //Error Flag
  
  //Sanitize data
  $username_sanitized = preg_replace('/[^a-z0-9\- ]/i','',$_POST['username']); //Allows only letters, numbers, spaces, and dashes in a username.
  $password_hashed = hash('sha512',$_POST['password'].$my_seed); //Notice we're converting the password to it's hash equivalent here -- hashes don't allow decryption!
  
  if ($user_details_query = $mysqli->query("select * from user_table where username LIKE '".$username_sanitized."' and password='".$password_hashed."'")) {
    //Notice that the database password is compared to the hashed password?  The original password is NEVER stored.  This is the advantage of using a hash to protect passwords.
    if ($user_details_query->num_rows > 0) {
      //All's well, so retrieve the user details for later
      $_SESSION['user_details'] = $user_details_query->fetch_object();
    } else {
      //Query executed fine, but no one was found who matches
      $login_error = true;
    }
  } else {
    //Some error in the database.  Really shouldn't get here.
    $login_error = true;
  }
  //Clean up after ourselves
  $user_details_query->close();
}
?>