in reply to Re^2: SaltedDigest Salt?
in thread SaltedDigest Salt?

Using a constant "secret salt" a bad idea, because identical passwords generate identical hashes. This makes attacks much easier than they should be: The bad guy sets his password to a common trivial password, say "123456", reads the login names and hashes from the DB, and instantly knows all logins that use this password simply because they have the same hash value as his account. Repeat for a long list of weak passwords and you will get a good list of login names and passwords.

It's less bad than storing the salts with the hashes.

And any salting process worth it ... um ... salt, would incorporate the userid into the hash along with the pass-phrase, which completely negates that problem.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Replies are listed 'Best First'.
Re^4: SaltedDigest Salt?
by packetstormer (Monk) on Feb 08, 2012 at 12:42 UTC

    Thanks, you've really cleared things up for me.
    It's got me thinking of using the random salt sting as some type of private key that, once generated, is encrypted and emailed to the user. Then it needs to be stored locally and part of the login in form, to the website, will ask the user for the location of the encrytped salt string along with their password.

    Anyway, I digress...apart from that ^^ mad idea, what way would you recommend for moderate/good security. That is, if you were implementing it. Would you store randomly generated salt in the database or just settle on one secret salt (that will need to be visible in the code)?
[reply]
      .apart from that ^^ mad idea,

      I certainly wouldn't use that idea.

      if you were implementing it. Would you store randomly generated salt in the database or just settle on one secret salt (that will need to be visible in the code)?

      I would write a small C program that has the secret salt embedded in it, encrypted. When run, it would check that it's parent was the webserver (or whatever other process is doing the authentication), and that its stdout is connected to a pipe. It would then decrypt the salt and write it to stdout. I'd make sure that the source code was not available on the server.

      I'd also ensure that the authenticating program combined the userid + passphrase + salt to generate the hash.

      Note:This is not recommendation! Just what I would do for a non-critical application.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?
[reply]

In Section Seekers of Perl Wisdom