Re: You're on SecurityFocus.com for the cleartext passwords.

On Sun, 07 May 2000, Tom Lane wrote:
> not the objective of this exercise.  The objective is to ensure that
> getting hold of the (hashed) Postgres passwords doesn't let you into
> *other* systems that a database user might have used the same
> (cleartext) password for.  We're trying to provide some security
> for other people's barns in the event that our own horses have already
> been stolen.

Ok, now I feel like this discussion has gone full circle and it is all very
clear to me.  The objectives are satisfied by the MD5 double salt scheme.  The
password itself is protected.  That doesn't protect the user.

I guess my point is about protecting your login and keeping others from getting
in there and doing things as you, in short, protecting the user. Sure, if the
cracker got the hashes, he got everything, but the accountability/blame
doesn't lie with one of the database users. The blame lies on the poor security
of the postgres superuser only.  When hashes alone are used for authentication,
it should not matter if someone gets the hashes - the hashes alone shouldn't be
enough let them in. Ordinarily, a cleartext password would go straight
through to the other end over a path that isn't sniffable or isn't even over a
network, like on a unix host when you login to a console.  But in Postgres'
case, you have the hash sent as an effective password from the client - it
doesn't send the actual password.  Anytime people really want a secure network
login, they have to use ssh, ssl, or pgp (pub/private key) software.  Those are
the only things that really protect user and keeps in control of their login. 
Your password might be secure, but your login still isn't.  Someone could get
the hashes and you might not ever know it.  They could login to the database
system as you for a long long time stealing your information and doing things
as you, but they'd never get your password.  The user could end up getting
blamed for some serious stuff that is not his fault.  The user doesn't have
control of his login.  The dba might realize that he had a security breach and
Bob's hash was stolen and used by a cracker to login as Bob and do serious
damage.  The db just shrugs it off and blames it on Bob, saying that Bob must
have compromised his clear text password.

I'd say under the scheme proposed, you really have to trust your dba and change
your password frequently.  Anyone with access to the hashes can login as you and
make you look bad.

-- 
Robert B. Easter
reaster@comptechnews.com