Re: Rejecting weak passwords
От | Marko Kreen |
---|---|
Тема | Re: Rejecting weak passwords |
Дата | |
Msg-id | e51f66da0909281100v2b3c4d01m4d3f10982d842ff6@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Rejecting weak passwords (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Rejecting weak passwords
Re: Rejecting weak passwords |
Список | pgsql-hackers |
On 9/28/09, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Actually there's a much bigger problem with asking the backend to reject > weak passwords: what ya gonna do with a pre-MD5'd string? Which is > exactly what the backend is going to always get, in a security-conscious > environment. Hmm... Looking at the docs, I don't see anywhere mention that the MD5 hashed passwords can still be used to log in, that only thing MD5'ing protects from is actually knowing what the password was. Also, although it does protect from sniffing password at login time, it is as insecure as plaintext password against sniffing on CREATE/ALTER USER time. Thus only secure way to change password is over SSL, in which case it does not make much difference whether it's plaintext or not. Logfile may seem to be as argument against plaintext, but note that you still cannot allow unprivileged users to access logfile that may contain MD5 passwords, as they can use them to log in as another user. So promoting the ENCRYPTED 'foo' as "secure" may lure users into false sense of security, and be lax against sniffing and logfile protection. Better approach seems to be simply refuse to log the password value into logfile, whether it's MD5 or not, and promote SSL as only secure way of changing passwords. IOW, having plaintext password in CREATE/ALTER time which can then checked for weaknesses is better that MD5 password, which actually does not increase security. We just need to fix the logging. -- marko
В списке pgsql-hackers по дате отправления: