Re: Authenticate with hash instead of plaintext password?

On Sun, 2012-12-16 at 17:51 +0100, Peter Bex wrote:
> 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.

Yes, but in that case they've already broken in. And this is about
making it much harder to discover the plaintext password in that case.

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

So PostgresQL, for instance, stores the actual plaintext password (or an
encrypted, but not hashed) password? And compares that with the hash
that it receives from libpq.

If so, then I just shouldn't be using that password for any kind of web
login.

[snip]
> 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).

That's not an option in this case. My system
( http://www.glom.org/wiki/index.php?title=Development/OnlineGlom )
is meant to provide access to databases and I don't wish to implement all
of it on the client side.)

I do have the option of creating a different set of user/password logins
for the web UI and then either
- Using one username/password for all web users' databases, with no
PostgreSQL-level separation. But this would have to be in a config file
at least. I guess this is what most web systems do, though they
generally deal with only one database.
- Generating PostgreSQL username/passwords for each web user's database,
but never exposing these to the web user. But I'd have to store them
somewhere.

murrayc(at)murrayc(dot)com
www.murrayc.com
www.openismus.com