>Your Salt should ALWAYS include a feature you have to store anyway about the user that would be unique to your service. What is your rationale for this? Is yo

>Your Salt should ALWAYS include a feature you have to store anyway about the user that would be unique to your service. What is your rationale for this? Is your concern is that a random salt will accidentally collide? With a 128 bit salt, there is a one in a million chance of a collision occurring in a set of 26 quadrillion. >UserName + PassWord + User ID + CreationDate + <Numerals from a Base64 encode of the users first and last name> That is just incredibly low entropy compared to a random string of bits. If you do this and use (as you suggest is just fine further down) MD5 or SHA1, you are begging for disaster if your site is worth attacking. >MD5 and Sha1 are only bad because there are rainbows for them Wrong. MD5 and SHA-1 both have significant vulnerabilities. >bcrypt is ... not any more secure if you did the other things above Insanely, completely, ridiculously wrong. MD5 and SHA-1 are stupid fast. A GPU-based cracker can try 5.6 billion MD5 hashes per second, and 2.3 billion SHA-1 hashes per second. If you're using a long random salt, you might hold out for a while after a data breach before all of your passwords are cracked. If you derive a low-entropy salt the way you explained above, you'll be completely boned.