Re: How passwords can be crypted in postgres?

GH wrote:
>
> It seems to me that the situation he describes would be one in which
> the frontend recieves an auth key ("password" or whatever) and then
> compares the hash of it to a value in the database. A similar situation
> would arise if the frontend merely passed the auth key to the database
> and the database hashed it and compared the hash to a stored hash.

If someone creates a front-end authentication mechanism of the type you
describe, they're in for a world of hurt.  The second scenario you
describe is very much how authentication is typically done, right?  Of
course there are things you need to do to make the process secure, like
wiping all trace of the unhashed password from memory as soon as
possible, controlling access permissions, etc.  But again, that's a
different subject.

There are many aspects to security.  The problem with this discussion is
that all of those different aspects are being mushed together into one
big jumble.

The original question was whether it is wise to store passwords in plain
text, or to store their hashed values.  The answer is it is better to
store the hashed values.  PGP encryption is also more secure, but you
face the additional risk of someone obtaining the meta-password.  The
advantage is that you can always rehash the password if you need to.
Like if you update an LDAP user directory with md5 hashed passwords
rather than crypted passwords, for example.  (i.e. - don't assume that
just because passwords are being stored in PostgreSQL, that
authentication is being done against PostgreSQL.  It might just be a
repository used for distribution.)

Taking care of other security aspects, like writing a program to do
authentication in a secure manner, or encrypting your network traffic,
is another topic altogether.

> Have fun.

Always ;)

-Ron-