From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Vince Vielhaber <vev(at)michvhf(dot)com>, The Hermit Hacker <scrappy(at)hub(dot)org>, "Sverre H(dot) Huseby" <sverrehu(at)online(dot)no>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: You're on SecurityFocus.com for the cleartext passwords. |
Date: | 2000-05-07 19:29:39 |
Message-ID: | 3915C423.37BE3331@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Tom Lane wrote:
>
> Hannu Krosing <hannu(at)tm(dot)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 choose to
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-05-07 19:34:09 | Re: So we're in agreement.... |
Previous Message | Vince Vielhaber | 2000-05-07 19:23:37 | Re: So we're in agreement.... |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-05-07 19:34:09 | Re: So we're in agreement.... |
Previous Message | Vince Vielhaber | 2000-05-07 19:23:37 | Re: So we're in agreement.... |