Re: [HACKERS] Enhancements to passwordcheck

Поиск
Список
Период
Сортировка
От Albe Laurenz
Тема Re: [HACKERS] Enhancements to passwordcheck
Дата
Msg-id A737B7A37273E048B164557ADEF4A58B7221F5FD@ntex2010i.host.magwien.gv.at
обсуждение исходный текст
Ответ на Re: [HACKERS] Enhancements to passwordcheck  ("Bossart, Nathan" <bossartn@amazon.com>)
Ответы Re: [HACKERS] Enhancements to passwordcheck  ("Bossart, Nathan" <bossartn@amazon.com>)
Список pgsql-hackers
Nathan Bossart wrote:
>>>         passwordcheck.force_new_password
>>>
>> Does it mean a password different from the old one? +1. It could be
>> different from the last 3 passwords but we don't store a password
>> history.
> 
> Yes.  As Michael pointed out, this might be better to do as a separate
> effort since we'll almost certainly need to introduce a way to store
> password history.

That increases the number of passwords stored on the server and
consequently the damage when that list is stolen.
Of course the old passwords are invalid, but if someone cracks them
they could still try them on other systems the person uses.

I think we should accept such a risk only if the benefits are clear, and
my opinion has always been that if you forbid password reuse, people
tend to come up with password generation schemes that are no better
than the original passwords.

> One interesting design challenge will be how to handle pre-hashed
> passwords, since the number of checks we can do on those is pretty
> limited.  I'm currently thinking of a parameter that can be used to
> block, allow, or force pre-hashed passwords.  If we take that route,
> perhaps we will also need to ensure that PostgreSQL fails to start when
> invalid combinations are specified (e.g. pre-hashed passwords are forced
> and min_password_length is nonzero).  Thoughts?

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.

Disabling pre-hashed passwords in order to allow better password
checks is a problem rather than a solution, because it exposes you
to password theft of the clear-text password.  I think we shouldn't
go there.

The overall opinion in the above thread was that if you *really* care
about security, you don't use database passwords, but external
authentication with a centralized identity management system.

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.

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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Setting pd_lower in GIN metapage
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] Setting pd_lower in GIN metapage