Re: Rejecting weak passwords - Mailing list pgsql-hackers
From | Mark Mielke |
---|---|
Subject | Re: Rejecting weak passwords |
Date | |
Msg-id | 4AD7685C.200@mark.mielke.cc Whole thread Raw |
In response to | Re: Rejecting weak passwords (Dave Page <dpage@pgadmin.org>) |
Responses |
Re: Rejecting weak passwords
|
List | pgsql-hackers |
On 10/15/2009 02:02 PM, Dave Page wrote: > On Thu, Oct 15, 2009 at 6:55 PM, Robert Haas<robertmhaas@gmail.com> wrote: > > >> OK, so we're in violent agreement here? >> > From a technical perspective I think we have been for a while. Though > clearly some people disagree with my assertion that putting any form > of policy enforcement in the client is not actually 'enforcement'. I > wonder how many of those folks would implement their website's data > sanitisation in the browser only - but I digress... :-) > It depends on what your goal is. If your goal is to treat users as monkeys that you do not trust, even with their own password, and the DBA as God, who you absolutely do trust, than you are correct. I don't know about your company - but in my company, the DBAs are in the IT department, and they really have no business knowing my password, which would give them access to my employee records, and my authorization capabilities. For any company that requires security, I do not accept that we can "trust the DBA". The database is just one small component in a much larger solution. The DBA is the monkey for a minor backend application, and the designers are the people earning money for the corporation. We have the exact opposite of what you are suggesting. A person can get access to much more data by logging in as the user on their *desktop* than by accessing some database directly. I think you are missing that security is a balance. Your dig at ignorant people who do JS-based browser side checks of input is not applicable. You are exchanging one type of security for another type of security. You think that your proposed type of security is more valid than my proposed type of security. It depends on the application. Sometimes you might be right. Other times, you have arguably made things worse. Any company that truly needs security of this sort - should not be using PostgreSQL based roles with passwords for authentication. The true value of your proposal is pretty limited. I'm not saying don't do it. I am saying that you are not truly achieving any improvement in security for the target audience you are saying that you are representing. I think your proposal might improve things for newbies running PostgreSQL on an open Internet port at home who pick username = password. Frankly, I don't think their data is worth protecting, and their choice to use username = password and make it accessible on an open Internet port confirms that they are either completely ignorant about security, or they also agree that their data is not worth protecting. Cheers, mark -- Mark Mielke<mark@mielke.cc>
pgsql-hackers by date: