Jump to content
Sign in to follow this  
ibinod

Encrypting password sha1(md5(md5(sha1(md5(sha1(sha1(md5($pass))))))))

Recommended Posts

Look create a form asking the user to enter there email address, and also somethink else u no

only what's in the database from joining your website.

 

Add your header and footer, call it forget_password.php.

 

Then add a link underneith the enter password form.

 

call the link example forgot password.......

 

afther doing all that, goto the forget_password.php page and create the code........

 

all you need is a simple update statement updating the password, where email and specil info match

there database entrys.........

 

 

 

 

Share this post


Link to post
Share on other sites

If the user forgets his/hers password, let your script generate a new one and send it to him. Then ask them to change it to their own.

 

Also, why char and not varchar?

 

Because it will always be 128 bytes long. Defining it as CHAR(128) has two benefits.

1. When reviewing database design it is implicit information, that all data in this column will have 128 bytes.

2. I've seen some articles saying that doing index search on CHAR is a bit faster than on VARCHAR.

 

Both of these are not really big benefits, but I like it to do it this way (mostly because of #1)

 

What about using sha256

 

Still pretty good, and 'only' 64 bytes :)

 

Here's a list of all hashing functions supposrted by hash(). You might want to look them up in Wikipedia or somewhere, and choose something you like most :)

 

Remember, using rare hashing function is also some security benefit :) (Although I'd say it's better to use something 'strong' than something 'exoctic')

Share this post


Link to post
Share on other sites

sha256 makes an sha hash twice as long as an md5 hash (which is 128 bits I believe). Theoretically (and logically) it means less collisions.

 

Whether you use sha or md5 really isn't a HUGE decider in your security.. pick a good salt and just don't worry about it until you need to :P

 

sha256 hashes are 64bytes long, while md5 are 20 bytes long. Just compare the size of rainbow tables for all alphanumeric strings composed of 8 bytes. But yeah. Salting is the key for secure hashes.

Share this post


Link to post
Share on other sites

Example only ok not tested but somethink to work on...........

 

<?php

if(isset($_POST['submit'])){

$email=mysql_real_escape_string($_POST['email']);

$s_info=mysql_real_escape_string($_POST['s_info']);

$sql="select * table where email='$email' and s_info='$_info'";

$res=mysql_query($sql)or die(mysql_error());

if(mysql_num_rows($res)==1){

	$r=rand(0,999999);

	$password=md5(sha1(md5($r)));

$up="update  table set password='$password' where email='$email' and s_info='$s_info'";

$res2=mysql_query($up)or die(mysql_error());

if(mysql_affected_rows($res)){

	echo"Thank you your new password been updated! <br>please now log in!";
}

}else{

	echo"Sorry we dont have a account with that info please try agin or join us!";
}
}

?>


// header.php

<center>

<form method="POST" action="<?php $_SERVER['PHP_SELF']; ?>">

<br><br>

please enter your email address!

<br><br>

<input type="text" name="email">

<br><br>

please enter your specil info

<br><br>

<input type="POST" name="s_info">

<br><br>

<input type="submit" name="submit" value="Password Request">


</form>

</center>

//footer.php

Share this post


Link to post
Share on other sites
sha256 hashes are 64bytes long, while md5 are 20 bytes long. Just compare the size of rainbow tables for all alphanumeric strings composed of 8 bytes. But yeah. Salting is the key for secure hashes.

 

sha256 is 256 bits...

- hence: 32 bytes long

- expressed as hex: 64 characters long

 

md5 is 128 bits..

- hence: 16 bytes long

- expressed as hex: 32 characters long

 

sha256 is twice as long as md5 any way you cut it. It's an understandable mistake though, it's hard to remember the length of all of these hashes.

Share this post


Link to post
Share on other sites

sha256 is twice as long as md5 any way you cut it. It's an understandable mistake though, it's hard to remember the length of all of these hashes.

Of course, length isn't everything

Share this post


Link to post
Share on other sites

I didn't bother reading the entire topic, but hashing multiple times will result in a higher risk of hash collisions thus decreasing the security. Use strong salting instead.

Share this post


Link to post
Share on other sites

sha256 is twice as long as md5 any way you cut it. It's an understandable mistake though, it's hard to remember the length of all of these hashes.

Of course, length isn't everything

 

Tell that to my girlfriend!

 

But yes, it's true. I see sha256 as an algorithm with nothing more than collision protection and a desire to fill my hard drive with hex numbers. I've said it and I'll say it again, I do nothing more than salt an md5 and it's served me well for many many many years.

 

edit: darn repeated words

Share this post


Link to post
Share on other sites

But yes, it's true. I see sha256 as an algorithm with nothing more than collision protection and a desire to fill my hard drive with hex numbers. I've said it and I'll say it again, I do nothing more than salt an md5 and it's served me well for many many many years.

 

edit: darn repeated words

I use ripemd128 with a binary salt derived from one element of non-displayed user information from the user record in the DB (Creation date/timestamp as binary) and one piece of information from the server environment. It serves me, and has passed a number of security audits.

 

Share this post


Link to post
Share on other sites

sha256 hashes are 64bytes long, while md5 are 20 bytes long. Just compare the size of rainbow tables for all alphanumeric strings composed of 8 bytes. But yeah. Salting is the key for secure hashes.

 

sha256 is 256 bits...

- hence: 32 bytes long

- expressed as hex: 64 characters long

 

md5 is 128 bits..

- hence: 16 bytes long

- expressed as hex: 32 characters long

 

sha256 is twice as long as md5 any way you cut it. It's an understandable mistake though, it's hard to remember the length of all of these hashes.

 

Yeah... I screwed my math big time...

Not only I confused MD5 with SHA1 (which outputs 20 byte long hashes), but then I confused bytes with hexadecimal digits for SHA256 :P

Share this post


Link to post
Share on other sites

Not tested but the full code.......

 

tincker with it ateast try it.........

 

<?php


$db=mysql_connect("localhost","username","password");

$result=mysql_create_db("database_name",$db)or die ('Database connection error'.mysql_errow());


if(isset($_POST['submit'])){
   
   $email=mysql_real_escape_string($_POST['email']);
   
   $email=mysql_real_escape_string($_POST['r_email']);
   
   $s_info=mysql_real_escape_string($_POST['s_info']);
   
   $r=mysql_real_escape_string($_POST['r']);
   
   
if(!preg_match("/[A-Za-z0-9\_\-]+@[A-Za-z0-9\-\_]+.[a-zA-Z0-9]+/",$email)){

echo"Sorry but your email is not valid";
}
   
   if( empty($email) || empty($r_email) || empty($s_info)){
   	
   	echo"Please fill in all the form!";
   
   }
   
   if($email())
   
   if($email==$r_email){
   
   $sql="select * table where email='$email' and s_info='$_info'";
   
   $res=mysql_query($sql)or die('Mysql select error'.mysql_error());
   
   if(mysql_num_rows($res)==1){

      $r=rand(0,999999);
      
      $password=md5(sha1(md5($r)));
      
   $up="update  table set password='$password' where email='$email' and s_info='$s_info'";
   
   $res2=mysql_query($up)or die('Mysql update error'.mysql_error());
   
   if(mysql_affected_rows($res)){
   	

$email=$eamil; 

$pasword=$r; 

$Messages='Thank you enjoy your new adventure here your password!'; // 

    
    $to = $email; // set the email address..........

$subject = 'Forgor Password!'; //subject of the email


//$mes is using caternation . << a dot

$mes = "Hello; $email <br><br> You have recieved an email from us about a new password<br><br>";
$mes .= "This message below is for your convenience. <br><br> ****************************** <br><br>";
$mes .= $email;
$mes .= "<br><br>";
$mes .= "Password: ";
$mes .= $password;
$mes .= "<br><br>";
$mes .= "Message: ";
$mes .= $Messages;
$mes .= "<br><br>****************************** <br><br>This Is An Automatically Generated Message, Do Not Repond!";

$message = $mes; 


$headers = 
        'X-Mailer: PHP/' . phpversion() . "\r\n" .
        "MIME-Version: 1.0\r\n" .
        "Content-Type: text/html; charset=utf-8\r\n" .
        "Content-Transfer-Encoding: 8bit\r\n\r\n";

// we are saying if the email is ent tell us using the email function.

if(mail($to, $subject, $message, $headers)){

// message was sent.

echo " MAIL WAS SENT TO $to!"; 

}else{

// message was not sent.

echo " SORRY NO MESSAGE SENT TO $to";
}

   	
   	
      
      echo"Thank you your new password been updated! <br>please now log in!";
   }
   
   }else{
      
      echo"Sorry we dont have a account with that info please try agin or join us!";
   }
}else{

echo"Sorry your emails diidnt match please try agin!";
}
}
?>


// header.php

<center>

<form method="POST" action="<?php $_SERVER['PHP_SELF']; ?>">

<br><br>

please enter your email address!

<br><br>

<input type="text" name="email">

<br><br>

please re enter your email address!

<br><br>

<input type="text" name="r_email">

<br><br>

please enter your specil info

<br><br>

<input type="POST" name="s_info">

<br><br>

<input type="submit" name="submit" value="Password Request">


</form>

</center>

//footer.php

Share this post


Link to post
Share on other sites

@redarrow:

 

[...] hashing multiple times will result in a higher risk of hash collisions thus decreasing the security. Use strong salting instead.

Share this post


Link to post
Share on other sites

md5() and a good salt does the trick for me. :) If someone wants to crack something, making it harder will make them want to crack it more. I'm not saying don't hash it or anything, just don't go overboard and what not. If people really really want in, they'll find a way.

Share this post


Link to post
Share on other sites

off topic but

 

taiths sig

"90% of computer issues exist between the seat, and the keyboard."

 

HAHAHAHAH

Share this post


Link to post
Share on other sites

Lodius, we refer to those as PEBKAC errors (preferably in front of the people with the problem)

 

Where the "problem exists between the keyboard and chair."

Share this post


Link to post
Share on other sites

For future readers of this thread, please disregard all of the advice about manually nesting or bit-shifting "fast" hashes like MD5, SHA1, SHA256, SHA512, etc. Attempts to create "hard to guess" methods are making a fundamental error in how to think about storing password hashes.

 

First, as was already mentioned, if the source code is compromised, no amount of obscurity will help you. Even if your algorithm isn't revealed at the same time as that particular data breach, that algorithm may be guessed later, or compromised later in a separate breach.

 

Second, the veil of obscurity is very thin. Tools like MDXfind are designed to try *many* different combinations and rounds, very quickly, in bulk. The password cracking "enthusiast" community goes to great lengths to reverse-engineer any novel algorithms. And they keep uncracked hashes around forever, and try all future discovered algorithms against the entire backlog. And they have seen many, many attempts at such obscurity, and they know them all.

 

Third, once the algorithm is known, tools like hashcat, John the Ripper, and MDXfind make very short work of combining many dictionaries and transformational rules to attack the target hashes. And many of these tools run at speeds of billions of guesses per second, which cuts through insufficiently stretched/rounded hashing schemes like a hot knife through butter.

 

In other words, relying on obscurity of the algorithm violates Kerckhoffs' Principle [1]: the idea that only the secret material, not the method of protection, should be required to be secret. In other words, if someone finding out exactly what your method is blows your security out of the water, you're doing it wrong.

 

Fortunately, you don't have to play that game, or try to out-think the password crackers. There's a simple, easy-to-use approach that consistently pisses them off (and I would know, because I am one of them):

 

Instead of inventing your own password storage mechanism, use phpass [2]. It was designed by password-cracking experts, expressly for the purpose of resisting high-powered cracking attacks while the underlying algorithm is already known. It supports using bcrypt, which is a password hashing method that was designed to be very resistant to high-speed password cracking techniques.

 

Do not get caught up in the "game" of trying to outthink the password crackers. -- because it's entirely unnecessary, and far inferior to the alternative.

 

At the hashing/storage level, phpass + bcrypt is the best way that you can make it hard for your users' passwords to be cracked.

 

Other tips:

 

* Allow long passwords (so random passphrases can be used) - at least 64 characters.

* Allow pasting passwords (so password managers can be used)

* Guide users towards using random passphrases (for passwords that must be memorized) and password managers with randomly generated passwords (for all other passwords)

* Only enforce complexity/composition requirements (min 1 digit, etc.) at shorter lengths

* In your apps, drop in frameworks like zxcvbn [3] - to provide rough password-strength feedback, and to blacklist well-known passwords

 

1. https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle

2. http://www.openwall.com/phpass/

3. https://github.com/dropbox/zxcvbn

Edited by tychotithonus

Share this post


Link to post
Share on other sites

This thread is 9(!) years old. Why on earth would you dig it out?

 

phpass is even older and has long been superseded by the native Password Hash API. It even says that right on top of the phpass page.

 

Yes, some threads on this forum contain nonsense, especially the ones which are a decade old. Anybody with basic common sense knows that. And if the age isn't enough, the fact that the participants keep mixing up hashing/encryption and guessing/decyption should make it clear that they have no idea what they're talking about.

 

The rest of your advice is fine, but you should use that for current threads. There's still more than enough to do even today.

Share this post


Link to post
Share on other sites

It's a fair point, especially about phpass vs the API (though cross-version portability might still be an issue for some users).

 

And generally a fair point about scope - as long as you're considering users who are regular inhabitants of PHP Freaks, and not people who arrive here because of a specific Google search. This thread kept coming up in some of my searches, so I dropped in the advice that I had, and moved on.

Edited by tychotithonus

Share this post


Link to post
Share on other sites

(though cross-version portability might still be an issue for some users).

 

All versions up to and including 5.5 have already reached end of life, so the password API should now be available in all common setups. If the server runs some kind of long-term-support version, there's a compatibility library which works exactly like the API but supports PHP versions down to 5.3.

 

 

 

And generally a fair point about scope - as long as you're considering users who are regular inhabitants of PHP Freaks, and not people who arrive here because of a specific Google search. This thread kept coming up in some of my searches, so I dropped in the advice that I had, and moved on.

 

Sure. I just have my doubts as to whether this is really helpful. Threads in a forum like this generally don't age well, because there's no proper mechanism for keeping them up to date or at least downvoting them (like on SO). You'll find the same problem – and much worse advice – in many other old topics, so trying to fix that seem futile. It's difficult enough to promote best practices in current threads.

 

Personally, I tell people to take all security-related advice with a grain of salt and just stay away from old threads. Security has never been a priority in the PHP community, and even the most basic concepts take a very long time until they're finally adopted. Posts from the last, say, 5 years may get it right, but anything before that is probably garbage.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.