Re: Rejecting weak passwords

On Thu, Oct 15, 2009 at 10:40 PM, Ron Mayer
<rm_pg(at)cheapcomplexdevices(dot)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