I thought I might have to run the inputted passphrase AND the same salt value through the algorithm to come up with the same hash?? Sorry for the dumb question but can anyone help?

In order to reproduce the hash, you need to store the salt as well as the hash it generates.

To obtain the salt used when you've specified salt_random, call the ->salt() or ->salt_hex() method and store it in the DB with the hash.

When authenticating, query both from your DB, set the salt explicitly, and hash the tentative password. If the result matches the one you stored when the password was created, it is authentic.

Update:

Of course, if the bad guys get at your DB, then they get the hashes and the asscoiated salts, so its value deteriorates.

To that end, you might want to consider storing the salts in a different place; or using just one common 'secret salt' that isn't stored anywhere in the DB.

To use a 'secret salt', your scripts still need to get it from somewhere. If you store it outside of your DB -- say, in the file-system or just hard-coded in the scripts themselves -- it is protected when your DB has been compromised. But if your systems are compromised, it is just sitting there waiting to be found.

One possibility is that the salt is supplied to the script or scripts that need it from the keyboard at start-up. This way they only exist in the memory of the running system and the head of the human that types it. Whilst much harder to find, it isn't convenient to drag the password holder out of bed whenever the system needs to be restarted after (the inevitable) crash. It is also not compatible with things like web-servers where the authentication script is short-lived and run gazillions of times.

A possible solution for the web-server and similar scenarios is that you have a separate machine that lives on your internal network, but is locked down to external access. This opens a port that responds to internal traffic only and exports the salt to correctly formatted queries. It lives in a physically secured cupboard, and gets the salt from the keyboard from the authorised holder. The analogy is the physical key cabinet that holds all the other keys in your traditional office.

Of course, at that point, why let the salt out into the front-end systems. Why not have the front-end scripts send the userid/tentative password to the secured server and have it perform the authentication and respond yes or no.

But then, if the bad guys have got into your front end machines, what's to stop them from intercepting the requests to the authentication server and just always responding 'yes'.

One view is that if the bad guys can get root access to your front-end servers, you're pretty much cooked anyway. Another is that the more layers there are, the harder it is for them to crack through them all.

To that end, you might want to consider storing the salts in a different place; or using just one common 'secret salt' that isn't stored anywhere in the DB.

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. This can't happen with random salt values.

The only advantage of a constant "secret salt" over not using a salt at all is that you need to generate a new set of rainbow tables for the specific salt value.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

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?

Of course, if the bad guys get at your DB, then they get the hashes and the asscoiated salts, so its value deteriorates.

Value of salt is that it prevents attacker from creating rainbow tables, if disclosure of salt compromises security of your system it is poorly designed, that's exactly the reason why cleartext passwords are bad. Additional problem with common secret salt is that you can't change it once it leaked.

the more layers there are, the harder it is for them to crack through them all

The harder for you to analyse and verify your security model, the more lines of code, the more bugs.

Value of salt is that it prevents attacker from creating rainbow tables,

It may prevent them from compromising all the accounts quickly, but it certainly does not prevent them from targeting selected accounts.

If the have both the hash and the salt, it becomes a matter of cpu cycles, and with AWS and other selling those so cheaply, it is just a matter of how much they are prepared to spend.

Value of salt is that it prevents attacker from creating rainbow tables,

I fail to see why? If you've been compromised, you surely need to change all the pass-phrases. At which point you have to rehash anyway.

I'm not saying a constant secret salt is a perfect solution, just convenient and relatively safe if done properly.

But then, there is no "perfect solution".

---

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?