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.
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.
> 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.
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). 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.
regards, tom lane