Re: You're on SecurityFocus.com for the cleartext passwords. - Mailing list pgsql-hackers
From | Hannu Krosing |
---|---|
Subject | Re: You're on SecurityFocus.com for the cleartext passwords. |
Date | |
Msg-id | 3915C423.37BE3331@tm.ee Whole thread Raw |
In response to | Re: You're on SecurityFocus.com for the cleartext passwords. (Bruce Momjian <pgman@candle.pha.pa.us>) |
Responses |
Re: You're on SecurityFocus.com for the cleartext passwords.
Re: You're on SecurityFocus.com for the cleartext passwords. |
List | pgsql-hackers |
Tom Lane wrote: > > Hannu Krosing <hannu@tm.ee> writes: > > One way to approach it in a semi-transparent way would be to add a > > column md5passwd to pg_shadow and set up a trigger to automatically > > update it whenever passwd is inserted/updated (and for > > security-concious people the same trigger would empty the passwd > > field itself, or set it to some special value that disables > > crypt/cleartext logins) > > I don't think it's optional to get rid of the cleartext password; > kindly recall the original complaint we are trying to address > (see subject line of this thread ;-)). So there's little value in > storing two columns. there is some value in A. a smooth transition path via dump/restore B. backwards compatibility for those that need it more than security - we can still do DES-crypt authentication if we chooseto later (say in 7.2) we can drop password and have only md5password > Also, by having just one password field we can deal with either > cleartext or pre-encrypted incoming passwords fairly easily. > The trigger either reformats the field, or not; no upstream code > needs to worry about whether the password is already encrypted. > So we don't need the "WITH ENCRYPTED PASSWORD" variant syntax, > which is a good thing IMHO. But how will you know if the data in the field is md5 hashed ? I know no way to tell for sure if an arbitrary string is a md5 hash or not. Of course we could choose a format like {MD5}:hashedstring and disallow cleartext passwords which start with {MD5}: like Zope does > > I still think that the easiest way to get unique hashes would be to use > > the username as salt when generating the value for md5passwd . > > No, I don't think that's an improvement. Please recall that the > original reason for inventing salt was to make sure that it wouldn't be > obvious whether the same user was using the same password on multiple > machines. Ok. My previous impression was that it was in order to make sure that two users on the same machine would not find out theat the other is using the same passord as she is > Since MD5 can take an arbitrarily long input phrase, we could possibly > run the calculation as MD5(password || username || random salt), but > there *must* be some randomness in there. > > I doubt that it'd be all that great an idea to include the username. > The biggest objection to it is that renaming a user would break his > password (nonobviously, too). Can we really rename users ? hannu=# create user foo; CREATE USER hannu=# alter user foo rename to bar; ERROR: parser: parse error at or near "rename" Why would one do it in the first place ? > The only reason in favor of it is that > it wouldn't be apparent when two different users share the same password > --- but the random salt covers that problem and does more too. True. I did not think of the one user/multiple computers scenario. ----------- Hannu
pgsql-hackers by date: