Member Avatar for antwan1986

Hi everyone and thanks for reading.

Up until yesterday I was unaware of this technique, and have always just ran a user's password through md5 and stored the result to the database. From what I've been reading about SALT it sounds like a very cool way of making your passwords practically uncrackable, but I have a question or two.

$pass = mysql_real_escape_string($_POST['password']);
$salt = 'a7dHsgQs0eiPsksd';
$password = md5($salt . $pass);

$sql = mysql_query("INSERT INTO table (password) VALUES ('$password')";

I understand what this code is doing and that after running it, my 'salted' password will be stored to the database, but when I'm checking a user's login attempt, will the code not be something like this?

$salt = 'a7dHsgQs0eiPsksd';
$pass = mysql_real_escape_string($_POST['password']);
$password = md5($salt . $pass);

$sql = mysql_query("SELECT * FROM table WHERE 'password' =  '$password' LIMIT 1";

So even though you've salted the password, the cracker can still type a common word in the text box, and have a chance of cracking the user's account, because I'm salting whatever they put? Or is SALT more of a security precaution for if ever your database got leaked and the crackers tried to reverse engineer the salted password?

Thanks for any clarification,


Anthony

  • 2 Contributors
  • 4 Replies
  • 126 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by antwan1986

Dani AI

Generated

Short answer for : salting + hashing protects the stored password data (an offline attack after a DB leak). It does not stop someone from trying guesses against your live login form. was correct on both points, but there are important modern details to add.

A few practical rules:

  • Do not use plain MD5 (even with a salt). MD5 is fast and unsuitable for passwords. Use PHP's built-in password hashing API which handles salts and uses slow, adaptive algorithms (bcrypt/argon2). See the PHP docs for password_hash and password_verify for recommended usage: password_hash and password_verify.
  • Store only the hash returned by password_hash. That string embeds algorithm, cost, and the salt. Use password_needs_rehash to upgrade hashes transparently after a successful login.
  • For additional protection against an offline attack, consider a server-side "pepper" (a secret stored outside the DB), but treat it carefully — it must be kept secret and rotated if compromised. The OWASP Password Storage Cheat Sheet gives current best practices: OWASP Password Storage.

A simple migration pattern:

$hash = password_hash($password, PASSWORD_DEFAULT); // store on registration

// on login
if (password_verify($password, $storedHash)) {
    if (password_needs_rehash($storedHash, PASSWORD_DEFAULT)) {
        $storedHash = password_hash($password, PASSWORD_DEFAULT); // update DB
    }
    // authenticated
}

To stop online guessing, combine slow hashing with login protections: rate limiting, progressive delays or backoff, cautious account lockouts, CAPTCHAs, IP throttling, strong logging, and (best) multi-factor authentication. Use HTTPS for all auth traffic. These measures, together with proper hashing, give real, layered protection.

Recommended Answers

All 4 Replies

Member Avatar for uncle_smith

Salt has nothing to do with sutiation where cracker can keep guessing passwords.

It will help in case where someone steels your database. You have to realize that md5 is not unhackable. There are many good ways to reverse the md5 hash back to the original value especially when the original value is a common word.

But when the salt has been added before the md5 is applied, then reversing to the original will be impossible.

So to answer your question - yes, good idea, do it. It will protect your database in case someone copies it or steals it any other way.

Member Avatar for antwan1986

So just to clarify, it's not the login process that it is protecting, it's the database side of things i.e. if the cracker was able to get access to the database, right?

Member Avatar for uncle_smith

So just to clarify, it's not the login process that it is protecting, it's the database side of things i.e. if the cracker was able to get access to the database, right?

Correct. YOu can't protect the login process with any tricks. If a lame user uses password 12345, the its a good change a cracker will guess it eventually, no matter what you do on the server side.

There are, however techniques to protect against password guessing. What you need to do is log the failed login attempts into a temporaty table, along with username, ip address and timestamp and then on every login attempt check that table and if the number of failed attempts > allowed preset limit withing the pre-set time interval, then show an error message that tells user that he must wait 10 minutes before trying again. Your script will then refuse any login attempts for that username, just dont check any more password for 10 minutes

That will help against robots trying to guess password.

commented: Good Explanation.... +3
Member Avatar for antwan1986

Thanks for all the help. Case solved!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.