If you use a static salt, you’re doing yourself a disservice; using a static salt is just as bad as using no salt at all. Once they break the salt, it’s just a matter of generating one new table and the database is just as compromised. Using a salt based on other user data (username, etc) is a step in the right direction, but dangerous if that data can ever change (as it will destroy your ability to check the password).

When using a random salt, leaving it in the generated string is just fine, because it will still require the cracker to generate a new table/attack vector for each individual password in the table, which is the goal of using the salt. You, however, will need to be able to retrieve that salt on a whim, so prepending it to the generated hash (as crypt automatically does) is a logical way of doing it.

One again, using a static salt is as bad as no salt at all. Check out that paper from M.I.T. linked near the beginning for info on why (long story short, once someone knows your never-changing salt they are in control, and they will find out). And, storing the generated salt right there with the password is a recognized A-OK technique. Generating a salt yourself every time couldn’t be easier:

crypt($password, '$2a$07$' . md5(microtime()));

Finally, if you wanted to store the salt string separately (or just want to be able to separate them), the hash is only the last 32 chars, e.g.

$hash_without_salt = substr($hash_with_salt, -32);

Since each salt makes the end encryption different? Wouldn’t this render this type of hashing completely and utterly pointless?

That being said, I cannot agree with you more that anything is vulnerable if someone is determined.

Chrome came along and it was an interesting browser to play with at first. As time went on, I found myself opening it more often just because I wanted something that would just work fast, when I needed it. Now, when in Windows, I almost never use anything else. And I find I don’t miss all of my extensions.