On Sun, Dec 16, 2012 at 05:38:37PM +0100, Murray Cumming wrote: > On Sun, 2012-12-16 at 17:24 +0100, Peter Bex wrote: > > What's the use of that? > [snip] > > I would not be storing the plaintext password anywhere. That makes it > harder for someone get the plaintext password if they break into the > server, and therefore harder for someone to use that password to break > into another account if the user has used the same password. If they do break in and are able to retrieve the password hash, they can still break in with that hash. Hashes (if properly salted and stretched) are only useful if they are only ever checked against the password itself. Storing a hash of any kind and comparing that directly with user input is equivalent to storing the password and comparing that with user input. > There have been plenty of high profile cases recently of password > databases being stolen, with those passwords being in plaintext, or > hashed without a salt, making user accounts on other systems vulnerable. > I'd like to avoid making the same embarrassing mistake. Please also avoid the mistake outlined above. Unless I'm overlooking something, then if there's a way to directly mediate between the browser client and the postgres server, you've effectively created a man-in-the-middle. This shouldn't be possible with a truly secure authentication mechanism. The best solution I can come up with is not provide a web UI at all but let the user connect directly to the database using a secure method (e.g. SSL client certs, GSSAPI etc). Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
