Rejecting weak passwords
in [PgSql]
|
From: "Albe Laurenz" on 17 Nov 2009 05:32 Itagaki Takahiro wrote: > I've reviewed your patch. The rough approach looks fine, > but I have some comments about function declarations and coding style. Thank you for taking the time! I think I addressed all the shortcomings you mentioned with the attached patches. I fixed the "{" alignment; I am not sure if there are any other spacing or alignment problems. Yours, Laurenz Albe
From: Heikki Linnakangas on 17 Nov 2009 06:41 I think it would better to add an explicit "isencrypted" parameter to the check_password_hook function, rather than require the module to do isMD5 on the password. Any imaginable check hook will need to know if the password is in MD5 format, and the backend already knows it (because it already did that check), it seems good to let the hook function know. Besides, if we introduce explicit syntax for saying that the supplied password is plaintext or md5 one day, calling isMD5 in the module will no longer be appropriate. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Albe Laurenz" on 17 Nov 2009 07:28 Heikki Linnakangas wrote: > I think it would better to add an explicit "isencrypted" parameter to > the check_password_hook function, rather than require the module to do > isMD5 on the password. Any imaginable check hook will need to know if > the password is in MD5 format, and the backend already knows it (because > it already did that check), it seems good to let the hook function know. > Besides, if we introduce explicit syntax for saying that the supplied > password is plaintext or md5 one day, calling isMD5 in the module will > no longer be appropriate. I agree on the second point, and I changed the patch accordingly. Here's the latest version. Yours, Laurenz Albe
From: Itagaki Takahiro on 18 Nov 2009 00:51 "Albe Laurenz" <laurenz.albe(a)wien.gv.at> wrote: > Heikki Linnakangas wrote: > > I think it would better to add an explicit "isencrypted" parameter to > > the check_password_hook function, rather than require the module to do > > isMD5 on the password. > > I agree on the second point, and I changed the patch accordingly. > Here's the latest version. Looks good. I change status of the patch to "Ready for Committer". BTW, it might not be a work for this patch, we also need to reject too long "VALID UNTIL" setting. If the password is complex, we should not use the same password for a long time. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Albe Laurenz" on 18 Nov 2009 05:35
Itagaki Takahiro wrote: > Looks good. I change status of the patch to "Ready for Committer". Thanks for the help! > BTW, it might not be a work for this patch, we also need to > reject too long "VALID UNTIL" setting. If the password is > complex, we should not use the same password for a long time. There are some cases, e.g. application servers logging into the database, where you cannot just let the password expire, so I think this would at best have to be a rule with exceptions. Another thing that makes VALID UNTIL inconvenient to use is that after expiration, logins simply fail, and the user is never prompted to change the password. But of course you are right, requiring a limited password lifetime is closely related to requiring a good password. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |