md5 password forgot

Newbie Spellweaver
Joined
Feb 4, 2011
Messages
96
Reaction score
1
Good night.

I have the following code for the forgot password, i'm using MD5 Encryption for the passwords, if i send the password for the e-mail, the password will be MD5, is there anyway to have the original password without being encrypted?

Code:
<?
$email=cleanInput($email);
$status = "OK";
$msg="";
//error_reporting(E_ERROR | E_PARSE | E_CORE_ERROR);
if (!stristr($email,"@") OR !stristr($email,".")) {
$msg="O teu e-mail não esta correcto<BR>"; 
$status= "NOTOK";}


echo "<br><br>";
if($status=="OK"){  $query="SELECT email,usuario,senha FROM usuarios WHERE email = '$email'";
$st=mysql_query($query);
$recs=mysql_num_rows($st);
$row=mysql_fetch_object($st);
$em=$row->email;// email is stored to a variable
 if ($recs == 0) {  echo "<center><font face='Verdana' size='2' color=red><b>Este e-mail não contém qualquer senha, por favor <a href='/contactos/contactoa.php'>contacta-nos</a></b><br> Desculpa, o teu e-mail não existe na nossa base de dados, cria uma conta <a href='registro.php'> aqui</a>.</center>"; exit;}

        $headers4="[email protected]";         ///// Change this address within quotes to your address ///
$headers.="Reply-to: $headers4\n";
$headers .= "From: $headers4\n"; 
$headers .= "Errors-to: $headers4\n"; 
//$headers = "Content-Type: text/html; charset=iso-8859-1\n".$headers;// for html mail un-comment this line

 if(mail("$em","Os teus detalhes","Esta é uma resposta automatica do Core5 \n \nNome de Usuario : $row->usuario \n A senha : $row->senha \n\n Muito obrigado, esperemos que continues a usar o Core5. \n \n Administrador do Core5","$headers")){echo "<center><font face='Verdana' size='2' ><b>Obrigado.</b> <br>Iremos enviar os teus dados para o teu e-mail em breve, verifica a tua caixa de entrada nos proximos segundos. </center>";}
else{ echo " <center><font face='Verdana' size='2' color=red >Existe algum problema em enviar os detalhes para o e-mail indicado, <a href='/contactos/contactoa.php'>contacta-nos</a>. <br><br><input type='button' value='Voltar atras' onClick='history.go(-1)'></center></font>";}


	} 

	else {echo "<center><font face='Verdana' size='2' color=red >$msg <br><br><input type='button' value='Voltar atras' onClick='history.go(-1)'></center></font>";}
?>

Ill wait a answer.
Wertex
 
I used to be a fool and store an MD5 version of the password and the raw version of the password in the database, which literally there is no point to. As said above, it's a lot better to just email the user a link to be able to set a new password.
 
Right, the md5 "decrypters" offer a service to encrypt your string into md5, while at the same time storing the raw version and encrypted version into a database.

Say you entered "password"

and got the return "5f4dcc3b5aa765d61d8327deb882cf99"

Now they have the decryption for "5f4dcc3b5aa765d61d8327deb882cf99", so searching that will return "password".

There is no way to crack the md5 encryption method.
 
Last edited:
Let's use the right terminology here:

MD5 is a hash. It is not an encryption. You can not decrypt a hash.
The most popular attack to decipher hashes is, as Chris and joopie were trying to explain, using a table of already known hashes. These are called rainbow tables.

To ensure password security, you want to hash, salt, and stretch the password, then store that in the database. You should never email them the plain text password (though it is possible to email them their plain text password at registration, though I don't recommend that either). You should never store the plain text password in the database.

When it comes to security, you really should not implement it yourself unless you're very intimate with it. Even I leave password security to professionally created, well tested scripts. I use phpass.
 
Let's use the right terminology here:

MD5 is a hash. It is not an encryption. You can not decrypt a hash.
The most popular attack to decipher hashes is, as Chris and joopie were trying to explain, using a table of already known hashes. These are called rainbow tables.

To ensure password security, you want to hash, salt, and stretch the password, then store that in the database. You should never email them the plain text password (though it is possible to email them their plain text password at registration, though I don't recommend that either). You should never store the plain text password in the database.

When it comes to security, you really should not implement it yourself unless you're very intimate with it. Even I leave password security to professionally created, well tested scripts. I use phpass.

Well, i have one friend on msn, that told me to use Base64, should i use it or is it easy to decode it?

Since i've seen this at google :

Base64 Decode and Encode - Online
 
Well, i have one friend on msn, that told me to use Base64, should i use it or is it easy to decode it?

Since i've seen this at google :

Base64 Decode and Encode - Online

Base64 offers no security. It's an encoding scheme often used to encode binary data in printable ascii characters which can be trivially transmitted over plaintext protocols (like HTTP or IRC).

MD5 is a hash, which means it sends all possible text inputs into a set of 128-bit values. There are 2^128 possible values for an MD5 hash. The reason it's not reversible is because this definition necessarily results in collisions. For instance, with 26 lowercase characters, 26 uppercase characters, and 10 digits, you have a 62 character keyspace. With 22 characters in this keyspace, you have 62^22 possibilities, which is roughly 2^131, which means with only 22 characters you are guaranteed collisions. So one cannot take a hash, like the hash of a 100MB file, and expect to be able to reverse it. It's more likely that the shortest string to collide with that is probably closer to 30 bytes long.

The reason MD5 isn't completely broken is the storage concern. Assuming a mapping from string -> MD5 values can be made onto with a maximal string length of 30 bytes (as in, with a list of 2^128 strings of length 30 at most, we can generate the entire space of all MD5 hashes), it will require 30*2^128 = 1.02e40 bytes of storage. This would require 8444249301319680 Yottabytes of storage. There is estimated to be a tad more than 300 Exabytes of data stored on all computers on Earth, and 1048576 Exabytes = 1 Yottabyte. There is no individual entity with enough storage to actually hold a perfect table, yet. If storage values doubled every year and we started with a rough estimate of 1 Exabyte, it would take just about 73 years before your average storage capability would reach that level. So MD5 won't be feasibly broken by a single index for a long while, barring any crazy breakthrough in storage density such as holographic storage (but we've been promised that since the 1980s).

This isn't a problem -- we've already started moving away from MD5 and towards SHA-1 and the newer SHA-2 and most recent SHA-3. SHA-1 is used by git and filesystems and has a 160bit digest size, compared to MD5s 128 bits. SHA-3 has an arbitrary digest size, but one implementation has a digest size of 1600bits.

That said, there are some well agreed upon ways of communicating securely, especially as far as passwords are concerned. You should always hash passwords with a salt. To do this properly, you should be performing a handshake authentication using HMAC, and each user should have a unique salt which should ideally be changed every time the password is changed. You can read more about HMAC authentication here: Hmac User Authentication. And it's always recommended to do all sensitive transfers of information over SSL. Cheap signed SSL certificates cost as little as $11/yr, which is cheaper in many cases than domain names, and provide more than enough security for your average site. Further, you should NEVER, EVER, EVER store personal data or personally identifying data about any individual who uses a service you create. Never. Check the headlines for how many major companies have been hacked and had their databases leaked. You're probably not capable of preventing that. The best way to avoid any major hassles is to simply store nothing of value for an attacker.

The beauty if the SHA-1 HMAC authentication outlined in that site is that the user has to determine the session key by signing some piece of text using the passhash generated by a given salt. The downside of this is that the session identifier isn't automatically placed in an HttpOnly or secure cookie. I would augment this by creating another step. Ideally, we create more than 1 session key, one persistent (HttpOnly for requests that don't mutate state, mainly GET requests), and another generated as-needed by the server that is required for state mutating operations (PUT/POST/DELETE/PATCH) to combat CSRF and very basic XSS attacks.
 
Last edited:
Right, the md5 "decrypters" offer a service to encrypt your string into md5, while at the same time storing the raw version and encrypted version into a database.

Say you entered "password"

and got the return "5f4dcc3b5aa765d61d8327deb882cf99"

Now they have the decryption for "5f4dcc3b5aa765d61d8327deb882cf99", so searching that will return "password".

There is no way to crack the md5 encryption method.

Haven't really used an md5 decryptor.
 
Back