Re: Rejecting weak passwords - Mailing list pgsql-hackers
| From | Mark Mielke |
|---|---|
| Subject | Re: Rejecting weak passwords |
| Date | |
| Msg-id | 4AC23469.4080400@mark.mielke.cc Whole thread Raw |
| In response to | Re: Rejecting weak passwords (Gurjeet Singh <singh.gurjeet@gmail.com>) |
| Responses |
Re: Rejecting weak passwords
|
| List | pgsql-hackers |
On 09/29/2009 09:07 AM, Gurjeet Singh wrote:
Reset on successful works _against_ the goal of preventing brute force attacks. Brute force attacks try until successful.
I read Josh's original suggestion to eventually evolve to "if a particular user account from a particular IP address uses the wrong password more than N times in T minutes, than the IP address is locked out for U minutes." This is the *only* way of significantly reducing the ability of a client to guess the password using "brute force".
It works pretty successfully in other systems. I know when I forget my voice mail password and I try five times, my account gets locked out for 24+ hours unless I request a password reset from our support organization. It is a pain in the butt - but it means that somebody trying to guess my password either has to get it right in a few short guesses, or they are out of luck.
Still, all of this seems a little bit over thought out to me, as unless one goes to this extreme - of actually blocking connections from an IP for a period of time - the ability to brute force passwords is already limited by network capacity, network latency, and protocol restrictions. md5 might be "broken" from the perspective of a super user having access to the md5 and having access to hardware accelerators (GPU), but brute forcing from a client to a server is still limited to thousands of attempts or less per second. This particular aspect of PostgreSQL has not concerned me. I tend to think that anybody who exposes their PostgreSQL to the Internet directly is asking for trouble no matter how hard pgsql-hackers tries to protect them. On my own network, there are so many other ways of getting at the passwords - including the crypt() passwords being visible over NIS using "ypmatch", that this is really the least of my concerns. We have employee agreements in place that prevent the use of "hacking", and outsiders are not supposed to have access to our network.
Point being - if you want to really be effective compared to what we have today - you need to go all the way. Half way is useless.
Cheers,
mark
On Tue, Sep 29, 2009 at 4:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:Josh Berkus <josh@agliodbs.com> writes:And the counts would be tracked and enforced where?
> Hmmm, that would be a useful, easy (I think) security feature: add a GUC
> for failed_logins_allowed.
Combining this with other suggestion:
.) Provide a GUC failed_logins_allowed
.) Add MAX FAILED LOGINS option to ADD/ALTER USER, which defaults to the GUC if not provided in the command.
.) Track per-user failed attempt counts in shared catalog, and reset on a successful login.
Reset on successful works _against_ the goal of preventing brute force attacks. Brute force attacks try until successful.
I read Josh's original suggestion to eventually evolve to "if a particular user account from a particular IP address uses the wrong password more than N times in T minutes, than the IP address is locked out for U minutes." This is the *only* way of significantly reducing the ability of a client to guess the password using "brute force".
It works pretty successfully in other systems. I know when I forget my voice mail password and I try five times, my account gets locked out for 24+ hours unless I request a password reset from our support organization. It is a pain in the butt - but it means that somebody trying to guess my password either has to get it right in a few short guesses, or they are out of luck.
Still, all of this seems a little bit over thought out to me, as unless one goes to this extreme - of actually blocking connections from an IP for a period of time - the ability to brute force passwords is already limited by network capacity, network latency, and protocol restrictions. md5 might be "broken" from the perspective of a super user having access to the md5 and having access to hardware accelerators (GPU), but brute forcing from a client to a server is still limited to thousands of attempts or less per second. This particular aspect of PostgreSQL has not concerned me. I tend to think that anybody who exposes their PostgreSQL to the Internet directly is asking for trouble no matter how hard pgsql-hackers tries to protect them. On my own network, there are so many other ways of getting at the passwords - including the crypt() passwords being visible over NIS using "ypmatch", that this is really the least of my concerns. We have employee agreements in place that prevent the use of "hacking", and outsiders are not supposed to have access to our network.
Point being - if you want to really be effective compared to what we have today - you need to go all the way. Half way is useless.
Cheers,
mark
-- Mark Mielke <mark@mielke.cc>
pgsql-hackers by date: