Rejecting weak passwords
in [PgSql]
|
From: Ron Mayer on 15 Oct 2009 12:59 Mark Mielke wrote: > On 10/15/2009 10:08 AM, Dave Page wrote: >> ...other >> DBMSs (and all major operating systems I can think of) offer password >> policy features as non-client checks...we are compared ... > > Not so clear to me. If they're doing strong checks, this means they're > sending passwords in the clear or only barely encoded, or using some > OTHER method than 'alter role ... password ...' to change the password. This makes it sounds like a documentation problem to me. We need to educate the security-feature-checklist writers. It seems we need to clearly spell out the security risks of sending plain text passwords in the section where we would state the reason why the checks are done in the client - and then hopefully the security checklists writers will include "only sends encrypted passwords" as a checkbox on the product comparison charts. And if server-side checks are that important, perhaps the wiki needs an example of how to enable server-side check for popular GSSAPI or LDAP or PAM configurations and describe how to make postgres use those. -- 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 15 Oct 2009 13:17 On 10/15/09 9:41 AM, Dave Page wrote: > Sometimes that can be for huge projects, where it is > necessary to justify every difference in check-box items against other > products to get past the early eval stages. Like it or not, that is a > fact, and this hampers our adoption. Precisely, and I think you've gotten away from that in your proposal. Any company who wants to institute a *truly* secure password policy is going to use LDAP, Kerberos, SSPI or GASSPI. Therefore what you're proposing is enabling band-aiding for the companies who don't want to really implement secure password control, but want to *feel* like they have. Why does this sound like a misfeature? Enabling the inclusion of a password checker in the client *would* improve things by preventing stupid users from setting their password the same as their username, or to a 3-letter word, or anything equally stupid which can be checked in a contextless way. This would be an real, incremental improvement *without* breaking anything else. And presumably would help our checkboxyness. I also think that it would be minimally intrusive to allow the PostgreSQL server to refuse connections from clients which didn't send a signal that they had the password-checker enabled. I *don't* think that guarding against users who are skilled enough to fake the password checker signal is worth *anyone's* time. First, a user that skilled presumably knows enough to pick secure passwords in the first place. Second, nothing Postgres can realistcally do in the way of password checking is going to protect us against a hacker with a knowledge of postgres internals. And, again, companies worrying about this are going to be using LDAP or GSSPI. Now, this thread has identified a number of areas where we could realistically improve password security: * Implement GASSPI encryption * Allow superusers to disable ALTER USER SET PASSWORD for normal users. * After the above, create a new createuser which works with ALTER USER disabled and uses a password checklib. * Implement the rest of the above suggestion. But I've seen nothing in Dave's other proposals which would *actually* improve password security as opposed to doing exactly the opposite. Requiring passwords to be sent unhashed over the wire so that they can be checked on the server is like making sure that your front door is always locked by giving keys to everyone you meet. In fact, given Dave's pursuit of a specific set of requirements, I think he has *one* specific client in mind rather than a generalized requirement. For my part, I've not in 10 years had anyone ask me for password checking in Postgres as an evaluation criteron. Encrypted data, yes. --Josh Berkus -- 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: Robert Haas on 15 Oct 2009 13:19 On Thu, Oct 15, 2009 at 12:23 PM, Mark Mielke <mark(a)mark.mielke.cc> wrote: > You miss my point (and conveniently cut it out). For users who accidentally > break policy vs users who purposefully circumvent policy - the approaches > must be different, and the risk management decision may be different. > > It's a lot easier to circumvent policy than most people (management > specifically) realize. If your attempt it to absolutely prevent a determined > competent individual from circumventing your policy - you need to do a LOT > MORE than what you are suggesting. > > If you just want to prevent accidents - having the client software do the > checks is fine. I don't get it. It's easy to circumvent client checks by using a different client. Circumventing server checks is really hard. You have to be able to hack the server. It seems obvious to me that putting the checks on the server is raising the bar by at least one order of magnitude and more likely two or three. Now, it's true that server-side checks on plaintext passwords are a security risk - in paricular, even with SSL, they can be captured by a modified server. So from the point of view of the *employee*, sending plaintext passwords may be less secure, because they don't know where their password is going. But from the point of view of the *server administrator*, they are more secure, because the server administrator believes (likely entirely correctly) that the odds of an employee picking a bad password (perhaps by firing up psql, which is not exactly a difficult-to-obtain utility) are higher than the odds that someone will trojan his server and install a password capture tool. If we were using some kind of real public key system and someone suggested breaking it to add password complexity checking, I would understand the outrage here. But I don't understand why everyone is so worked up about having an *optional* *flag* to force plaintext instead of MD5. I might be wrong here, but can't a determined attacker brute-force an MD5 anyway? The very fact that people are suggesting that password checking might be feasible even on a pre-MD5'd password by using a dictionary suggests that we're not getting a whole lot of real security here. And even if not, dude, it's an *optional* *flag*. Document that using it has certain advantages and certain disadvantages, and let users make their own decision about whether to deploy it. If they make a bad decision and get hacked as a result, tell them it's their own darn fault for setting the flag. I reiterate my previous opposition to the idea that "I wouldn't use that feature" is a reason not to add it. ....Robert -- 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 15 Oct 2009 13:43 Robert Haas <robertmhaas(a)gmail.com> writes: > If we were using some kind of real public key system and someone > suggested breaking it to add password complexity checking, I would > understand the outrage here. But I don't understand why everyone is > so worked up about having an *optional* *flag* to force plaintext > instead of MD5. I might be wrong here, but can't a determined > attacker brute-force an MD5 anyway? The very fact that people are > suggesting that password checking might be feasible even on a > pre-MD5'd password by using a dictionary suggests that we're not > getting a whole lot of real security here. And even if not, dude, > it's an *optional* *flag*. Yes, and it's an optional flag that could perfectly well be implemented in the plugin that I think we do have consensus to add a hook for. The argument is over why do we need to litter the core system with it. 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: Dave Page on 15 Oct 2009 13:44
On Thu, Oct 15, 2009 at 6:17 PM, Josh Berkus <josh(a)agliodbs.com> wrote: > Enabling the inclusion of a password checker in the client *would* > improve things by preventing stupid users from setting their password > the same as their username, or to a 3-letter word, or anything equally > stupid which can be checked in a contextless way. This would be an > real, incremental improvement *without* breaking anything else. And > presumably would help our checkboxyness. What client? For the vast majority of users, what you're proposing is 'do it yourself'. Most people don't use pgAdmin or psql. > But I've seen nothing in Dave's other proposals which would *actually* Actually, I made just one proposal, to complement a patch that has already been submitted. > improve password security as opposed to doing exactly the opposite > Requiring passwords to be sent unhashed over the wire so that they can > be checked on the server is like making sure that your front door is > always locked by giving keys to everyone you meet. As Peter pointed out, it's already game-over if you're worried about the DBA. For other cases, I was clear that SSL should be expected. > In fact, given Dave's pursuit of a specific set of requirements, I think My only request was for server-side password policy enforcement, and a way to ensure users/DBAs could use pgAdmin to manage those passwords. > he has *one* specific client in mind rather than a generalized > requirement. For my part, I've not in 10 years had anyone ask me for > password checking in Postgres as an evaluation criteron. Encrypted > data, yes. I don't deal with prospective clients, which is where this comes from. I do deal with a team of (pre)sales engineers who complain about this, and maybe half-a-dozen other issues on a very regular basis. They tell me that PostgreSQL loses out in early stages of tech evals because of this issue, and I have no reason to disbelieve them. Sure it's almost certainly not the only reason, but they add up. And yes, data encryption is one of the other checkbox items that they bleat about. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.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 |