0

i am trying to append a randomly generated salt along with my md5 generated password. So how can we recheck the salted password? DO we need to save salt along with the password in the Db. Is this a good approach.

$pass='password';
$salt = substr(str_shuffle('0123456789abcdefghijklmnopqrstuvwxyz'), 0, 12);
echo md5($pass.$salt);

Also please tell me if this is the proper way of salting???

Sibu
  • 4,609
  • 2
  • 26
  • 38
  • `str_shuffle(range(0, 9) . range('a', 'z'))` – alex Oct 26 '11 at 12:15
  • Generally a salt is a random string you prepend to the password before you hash it, and you often repeat the salt+password sequence say 60 times to hash. So yes, you need to store the salt along with the hash. Many implementations store both in the same field, e.g. 10 bytes of salt and 16 bytes of hash. – Rup Oct 26 '11 at 12:15
  • @delnan i have those resources, but tell me isn't storing salt along with hashed password in Db a security issue. If my cpanel is hacked hackers will know salts and i think system will be compromised – Sibu Oct 26 '11 at 12:21
  • 1
    @Sibu, If hackers break your cpanel, your system is way beyond compromised, regardless of if they know your salts or not. – JackWink Oct 26 '11 at 12:24
  • 1
    That's addressed in most of the salting articles I have seen. Long story short, the salt only helps you go from a plain-text password to the full hash, not the other way around. One key property of (not completely broken) cryptographic hashes, the wildy varying output for similar inputs, prevent guessing the rest of the input (the password) from a hash output. –  Oct 26 '11 at 12:26

6 Answers6

8

The point of a salt is to avoid rainbow table attacks, or precomputed password hashes. In order to check the old password, you'll need to use the same salt you hashed it with, so you do need to store it, e.g. in the DB.

Md5 isn't a strong crypto hash, and you are probably best using bcrypt. There is a free PHP implementation http://www.openwall.com/phpass/.

That will have much stronger salting, and hashing.

JackWink
  • 666
  • 3
  • 10
7

DO we need to save salt along with the password in the Db.

yes.

Also please note that all this romantic hashing-salting stuff has absolutely nothing to do with your site security

Your Common Sense
  • 156,878
  • 40
  • 214
  • 345
  • 1
    it is a *common sense* issue. How it is supposed to generate the same hash without a salt? – Your Common Sense Oct 26 '11 at 12:19
  • hashing + salting has a lot to do with site security... sure it doesn't prevent SQLi, XSS, but it proper hashing will slow down the login process, avoiding brute force/timing attacks. Salting is to avoid going from hash -> plaintext in case your db is popped. – JackWink Oct 26 '11 at 12:32
  • @JackWink that's what I am talking about. in case your db is popped, the site is ALREADY compromised. and your mention of bruteforcing is ridiculous :) in case you're using slow hashing to prevent bruteforce, the bruteforce become a DOS. – Your Common Sense Oct 26 '11 at 12:40
  • @JackWink: In case your DB pops, the salt *is visible*. – hakre Oct 26 '11 at 12:41
  • @Col.Shrapnel, From a secure system standpoint it's better to block/ban an IP DoSing than to have your system compromised... My bad on db example though – JackWink Oct 26 '11 at 12:46
2

It's good to have a salt. Now, the way you generate and store it is up to you. You could as well just store the date and time of the last login and use it as the salt - this way you don't explicitly store the salt and it changes with each new login (naturally, this also means the password hash is always different). It's totally up to you.

You could actually have several salts - perhaps one or more coming from the database (MD5(last_login), SHA1(username)...), and another one hardcoded in your PHP application.

mingos
  • 23,778
  • 12
  • 70
  • 107
  • Actually, you want a random salt, generated from a cryptographically secure source. Generating a salt from userdata isn't good practice. – JackWink Oct 26 '11 at 12:26
  • 1
    I never said it was - but it's a choice the dev has. And it's always better than no salt. Plus, if I understand the OP correctly, the question is about storing the explicit salt string. Do you consider that a better practice than generating it on the fly from several sources? – mingos Oct 26 '11 at 12:30
  • 1
    No, what he's doing is wrong. He should be attempting to read from `dev/urandom` first to get random bytes, or in the worst case, hashing microtime. I'm not saying you didn't give a helpful answer, just that this isn't the best or most secure method. There's an interesting post on it here: http://stackoverflow.com/questions/536584/non-random-salt-for-password-hashes/536756#536756 – JackWink Oct 26 '11 at 12:37
  • No problem, glad you liked it :) – JackWink Oct 26 '11 at 12:58
1

Yes it is important to store salt in the database - if the salt is compromised in the database then the one-way encryption to validate your password will fail so no worries.

Barry Kaye
  • 7,682
  • 6
  • 42
  • 64
0

As long as it is not a shared salt for all passwords you need to store it to the database or generate it from values that won't change (e.x. user id).

You could do this in a salt field or in the hash itself (see phpass for a good implementation example)

In short: Generally yes!

Hikaru-Shindo
  • 1,891
  • 12
  • 22
0

I would say you need to save it in the database. How else would you save a random salt? For more info check: http://crackstation.net/hashing-security.html

CodeZombie
  • 5,367
  • 3
  • 30
  • 37