Rejecting weak passwords
in [PgSql]
|
From: Tom Lane on 29 Sep 2009 10:50 Robert Haas <robertmhaas(a)gmail.com> writes: > But how much value is there in that? This whole thing seems like a > dead end to me. No matter how long you're willing to wait, putting > the checking on the client side will let you far more validation for > the same price. No doubt, but ... The value of doing it on the server side is you only have to implement it once, and you don't have to hope that all your users are using the most up-to-date clients that will enforce a check. (The more troglodytic of them might be using a direct ALTER USER PASSWORD command, which will certainly not result in any client-side check happening.) Even if we encouraged client-side tool authors to implement password checking, the lack of consensus about what the checks should be would pretty much guarantee lack of uniformity about exactly what got checked in any real installation. Which is not the sort of thing that makes security auditors feel all warm and fuzzy. regards, tom lane -- 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: Tom Lane on 29 Sep 2009 11:02 Andrew Dunstan <andrew(a)dunslane.net> writes: > Why do we need to answer that question? If all we do is provide a hook, > the cost is very low, and the decision on value is left to whoever is > deploying some module to use the hook. Right. As long as it's just a hook, it's not enough work to justify lots of debate. There is a plausible use-case, and that's enough. regards, tom lane -- 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: Josh Berkus on 29 Sep 2009 12:54 Mark, > 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". As pointed out by others, that was a false assertion. Most sophisticated attackers sniff the MD5 password over the network or by other means, and then brute force match it without trying to connect to the DB. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.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: Mark Mielke on 29 Sep 2009 14:58 On 09/29/2009 12:54 PM, Josh Berkus wrote: >> 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". >> > As pointed out by others, that was a false assertion. Most > sophisticated attackers sniff the MD5 password over the network or by > other means, and then brute force match it without trying to connect to > the DB. > I don't know about most. Sniffing requires an inside track. I cannot sniff your network traffic from my notebook in Ottawa. Somebody so inclined would have to first break into your network to see the password you are sending. Then, if they can sniff your traffic, they can do all sorts of other things. It's a bit of a wash in the grand scheme of things. In practice, for the last decade, I have seen peaks of tens of thousands of attempts a day to brute force into my machine from the Internet from locations all over the world. It is not limited to telnet or SSH either - they come in on IMAP ports, VNC ports, SMB ports, or anything else that is widely used and exposed. Brute forcing through remote login is a well used method of cracking. Still, their ability to guess is limited by network capacity and network latency. So, it is on the order of thousands, not millions, and basic password precautions such as "don't use a word" are still quite effective. I don't think knowing the MD5 is an attack on its own. It might be a component in an escalation vector whereby the first get access to one resource, and then sniff the MD5 or see it in the backend database storage, to break into another resource. In any case - if they get the MD5, PostgreSQL is already compromised, and the next attack is more likely to affect something else - not PostgreSQL itself. Within our company, the crypt() passwords are available to all employees via NIS. Technically, this is a problem - but in practice, how much effort is this worth resolving? If they can get onto our network to get access to the crypt() password, they probably already have access to other intellectual property. Mostly - I'm saying that PostgreSQL using MD5 is a minor issue - switching to SHA-1 is not going to eliminate the problem, it will just make things a tiny bit harder for a would be attacker. To actually close the window, as opposed to push it closed a little tighter, would take a lot more effort. Cheers, mark -- Mark Mielke<mark(a)mielke.cc> -- 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 1 Oct 2009 08:53
In the discussion following http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php the consensus was that a hook that allows you to implement a password checking routine as a module "would not hurt". So here's the patch. I don't think there is documentation required; correct me if I am wrong. Yours, Laurenz Albe |