Skip site navigation (1) Skip section navigation (2)

Re: Rejecting weak passwords

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Dave Page <dpage(at)pgadmin(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, mlortiz <mlortiz(at)uci(dot)cu>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rejecting weak passwords
Date: 2009-09-29 14:50:03
Message-ID: 9212.1254235803@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> But how much value is there in that?  This whole thing seems like a
> dead end to me.  No matter how long you're willing to wait, putting
> the checking on the client side will let you far more validation for
> the same price.

No doubt, but ...

The value of doing it on the server side is you only have to implement
it once, and you don't have to hope that all your users are using the
most up-to-date clients that will enforce a check.  (The more troglodytic
of them might be using a direct ALTER USER PASSWORD command, which will
certainly not result in any client-side check happening.)

Even if we encouraged client-side tool authors to implement password
checking, the lack of consensus about what the checks should be would
pretty much guarantee lack of uniformity about exactly what got checked
in any real installation.  Which is not the sort of thing that makes
security auditors feel all warm and fuzzy.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Petr JelinekDate: 2009-09-29 14:52:02
Subject: Re: [PATCH] DefaultACLs
Previous:From: Andrew DunstanDate: 2009-09-29 14:47:08
Subject: Re: Rejecting weak passwords

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group