Nathan Bossart wrote:
>> As was pointed out in the original discussion
>> D960CB61B694CF459DCFB4B0128514C203937F49@exadv11.host.magwien.gv.at
>> the weak point of "passwordcheck" is that it does not work very well
>> for encrypted passwords.
>> The only saving grace is that you can at least check against
>> username equals password.
>
> Thanks for linking the original thread. There are a lot of
> interesting points. I wonder if enhanced password checking in core
> or contrib might be received differently with the introduction of
> SCRAM authentication, since the weaknesses of MD5 were often cited.
I had the impression that the reasons why database passwords are
not the best option for high security were:
1) The password hash is stored in the database and can be stolen and cracked (don't know if dictionary attacks are
harderwith SCRAM).
2) The password or the password hash are transmitted to the server when you change the password and may be captured.
>> So I think it is fine to extend "passwordcheck", but we shouldn't
>> take it serious enough to reduce security elsewhere in order to
>> improve the module.
>
> I understand the points made here, but not allowing configurability
> here really hinders the module's ability to enforce much of
> anything.
I agree that it is a good thing to make "passwordcheck" configurable.
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers