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.

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.

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.

"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.

The salt is typically stored in the password db, alongside the salted hash.

If Adobe has taken that approach, the intruders would have all the salts, but they would not be able to do this attack of seeing how many people use the same password.

However, Snowden's silly password hint would still have given the game away. If that is in fact him.