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
