Rejecting weak passwords
in [PgSql]
|
From: Tom Lane on 15 Oct 2009 14:16 Dave Page <dpage(a)pgadmin.org> writes: > I suppose in the worst case, I could just have pgAdmin throw the > error, and then add a per-server option to disable password hashing in > the relevant places, but I'd far rather have that automated so it > can't be set unnecessarily. As I commented before, I think that automating this is actually a dangerous misfeature. 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: Mark Mielke on 15 Oct 2009 14:22 On 10/15/2009 02:02 PM, Dave Page wrote: > On Thu, Oct 15, 2009 at 6:55 PM, Robert Haas<robertmhaas(a)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(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: Dave Page on 15 Oct 2009 14:54 On Thu, Oct 15, 2009 at 7:22 PM, Mark Mielke <mark(a)mark.mielke.cc> wrote: > 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. You have no choice but to trust the DBA (or sysadmin) if you use PostgreSQL's built in authentication. Just set a pg_hba.conf line to 'password' and start harvesting passwords. > 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 never said it wasn't - in fact I said from the outset it was about box-checking, and that anyone doing things properly will use LDAP/SSPI/Kerberos etc. What I did say, was that my proposed GUC doesn't allow the DBA to do anything that he cannot already do in a much easier way, per the comment above. Anyway, as noted in the message you quoted, the current proposal will allow my colleagues to check boxes, and will be implemented in a sensible way on the server side. And it's entirely confined to a plugin, so if you trust all your users, there's no need for you to load it at all. -- 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
From: Ron Mayer on 15 Oct 2009 17:40 Dave Page wrote: > I never said it wasn't - in fact I said from the outset it was about > box-checking, and that anyone doing things properly will use > LDAP/SSPI/Kerberos etc. I don't understand why the box-checkers can't already check that box; with the explanation stating "Yes - by using LDAP or GSSAPI or PAM configured accordingly". Or do checkbox-lists specifically say "can postgres do XYZ with all OS security features disabled". > Anyway, as noted in the message you quoted, the current proposal will > allow my colleagues to check boxes, and will be implemented in a > sensible way on the server side. And it's entirely confined to a > plugin, so if you trust all your users, there's no need for you to > load it at all. Note that I'm not horribly against the feature (though I wouldn't use it) --- just that ISTM we're checkbox-compliant already by working with the OS, and it's perhaps more a documentation issue than coding issue to get those boxes checked. -- 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 18:13
On Thu, Oct 15, 2009 at 10:40 PM, Ron Mayer <rm_pg(a)cheapcomplexdevices.com> wrote: > Dave Page wrote: >> I never said it wasn't - in fact I said from the outset it was about >> box-checking, and that anyone doing things properly will use >> LDAP/SSPI/Kerberos etc. > > I don't understand why the box-checkers can't already check that > box; with the explanation stating "Yes - by using LDAP or GSSAPI > or PAM configured accordingly". > > Or do checkbox-lists specifically say > "can postgres do XYZ with all OS security features disabled". Well I guess that's possible, but what I hear our SEs complaining about is having to justify features that require additional software or features that other DBMSs offer natively. Let me offer a couple of examples: Q. Does the product offer password policy enforcement? Oracle: Yes SQL Server: Yes PostgreSQL: Yes (using an external authentication provider with policy enforcement). Q. Does the product support external authentication providers? Oracle: Yes SQL Server: Yes PostgreSQL: Yes Q. Does the product offer transparent data encryption? Oracle: Yes SQL Server: Yes PostgreSQL: Yes (using an encrypted filesystem). Q. Does the product offer audit capabilities? Oracle: Yes SQL Server: Yes PostgreSQL: Yes (must be manually implemented using triggers and functions) Too many of those caveats, and it's easy to see how we can be discounted early in the evaluation phase. It's not helped that often these lists will be drawn up by people used to working with the commercial DBMSs, so we probably wouldn't get extra points for having a dozen procedural languages, or other features that are largely unique to PostgreSQL, no matter how cool and useful they are. -- 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 |