security_postgresql

This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.



Subject: Re: [HACKERS] You're on SecurityFocus.com for the cleartext
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
Date: Tue, 9 May 2000 14:02:17 -0700

If I understand the original objection it's that passwords are stored 
in cleartext on the postmaster machine.  That's not much of an 
objection since you have to have your secrets available in the clear 
on both ends of a connection if you want the traffic on the 
connection secured.  Both the Solaris and NetBSD ppp implementations 
have this characteristic.  Kerberos IV encrypts the passwords on the 
server, but the master password for that encryption is still stored 
in "/.k" so it's the same in principle.

If I understand the current password implementation the postmaster 
chooses the salt, sends it to the client which does a unix crypt and 
returns the encrypted password for verification.  This is a nice, 
simple system which provides what I would consider a reasonable 
minimum of security.

But it's not *really* secure.  For one thing a bad guy could 
intercept the encrypted password and feed it to one of the 
password-guessing programs, like crack.  It's not very robust to 
man-in-the-middle attacks, either.  Do we know how predictable the 
salt-choosing algorithm is?  What if a counterfeit server requested 
authentication with a carefully-chosen salt (like 0)?

We are not in the business of creating security protocols.  IMHO we 
should leave that to the people who are.  If we want something better 
than the password scheme we have then we should adopt an existing 
standard.  Chap, as used with ppp, comes to mind.  It might be a good 
substitute for the password protocol.

Remember that we already support kerberos.  Also there is no reason 
you can't run the connection over an ssh tunnel.  That solution would 
protect the data as well as the passwords.  There are applications 
where the important information is not what's in the database, but 
what information did someone want from it and when did they ask.

Out of curiosity does SecurityFocus.com also criticise pppd for the 
same "problem"?  The problem is not us storing the passwords in the 
clear, but rather are we careful about the access permissions on the 
file that contains them, and are we careful about how they get passed 
around.

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu

===


the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu