[sillysaurus2]

Salts aren't secret. The point of salting a password is to prevent the password (like "alskdjfalsdf") from always hashing to the same result (like "j9p+HwtWWT86aMjgZFLzYg=="). That prevents rainbow table attacks (among others) and it doesn't require the salt be secret.

[jsmeaton]

Right. But the parent comment was replying to a comment suggesting that a user id (or other account information) shouldn't be used as it's not random.

I can't see why a user id could not be used as a salt though.

[cbr]

If lots of sites all use user ids as a salt and all count up from 1 then a much weaker version of this attack applies: you can identify all the people who have both the same password and the same user id.

If this were common, someone constructing a lookup table for password hashes could include ones salted with the first N user ids. A N-times bigger table isn't something you'd be excited about as a cracker, but might still be practical.

If your user ids are randomly assigned this should be pretty much the same as generating a random salt. Still, the extra storage of a salt is going to be small compared to whatever else you're storing per-user, so better to do the safe thing and go with what's standard.

[justincormack]

"I can't see why a user id could not be used as a salt though" thats exactly how people break crypto implementations, it seems ok but you dont really know. Don't just invent your own way, use the standard one.