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

[redarrow]

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.........

 

 

 

 

[Mchl]

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')

[Mchl]

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

 

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.

[redarrow]

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

[genericnumber1]

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.

[genericnumber1]

edit: nevermind, the comment to which I was replying no longer exists.

[Mark Baker]

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

[Daniel0]

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.

[genericnumber1]

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

[Mark Baker]

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.

 

[Mchl]

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

[redarrow]

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

[Daniel0]

@redarrow:

 

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

[JasonLewis]

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.

[Lodius2000]

off topic but

 

taiths sig

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

 

HAHAHAHAH

[genericnumber1]

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."

[tychotithonus]

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 September 10, 2017 by tychotithonus

[Jacques1]

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.

[tychotithonus]

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 September 25, 2017 by tychotithonus

[Jacques1]

(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.