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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
