Joshua Drake wrote: > If you aren't paying close enough attention to your database server to > see that someone is trying to brute force your MD5 password you have > bigger problems.
Everybody is completely missing the point. :-( The point of a random salt is *NOT* to increase the security of your particular PostgreSQL installation. A random salt won't help that at all. The point of the random salt *IS* to make it harder for an attacker who has compromised your system to derive the plain-text passwords from the hashes. Attackers love to derive plain-text passwords because the odds are very good they can be used to compromise a *different* system. (Come on, be honest, how many people here have the same password on more than one system, or the same PostgreSQL password as UNIX login password?) The "information leakage" scenario mentioned earlier, whereby attackers could determine valid user names, is trivial to defeat: If the user name exists, return the salt in the password table. If not, return an algorithmically derived salt md5(username + x) where "x" is some server-wide parameter that's set to a random number upon installation. We have an application that requires customers to log into our site. We store passwords in cleartext. However, these passwords are randomly generated *by us* and we don't allow customers to choose them. So if our server is compromised, (a) we don't care if the attacker gets the customers' passwords, because they've already compromised the server, and (b) the customers' passwords are useless for anything else, so the security of our customers is not compromised. Regards, David. ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match