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.