* mark@mark.mielke.cc (mark@mark.mielke.cc) wrote:
> On Tue, Dec 05, 2006 at 11:32:40AM -0500, Tom Lane wrote:
> > Gavin Sherry <swm@linuxworld.com.au> writes:
> > > Now, in the presence of encrypted passwords being sent across the wire, we
> > > can't do anything. So, we export the password strength tester to libpq.
> > As already noted, that seems approximately useless.
>
> Telling the users they are being stupid isn't useless - but yeah, it sounds
> like a domain that should be covered by a tool other than PostgreSQL.
>
> PAM sounds about right, and PAM already has this functionality.
PAM is simply not always an option, unless you want to figure out a way
to use PAM modules without using /etc/passwd and company. Currently the
only way to use PAM w/ password-changing done in PG is to chown all the
various files and whatnot over to being owned by Postgres, which is a royal
pain and a very ugly mess. I suppose another option would be to
convince PG to run as root but that's not exactly an encouraged setup
either.
I wouldn't be against using cracklib (outside of PAM) tho.
> > This is a waste of effort, unless you propose to put the delay into both
> > the success and failure paths, which hardly seems acceptable. Otherwise
> > a guesser need only abandon the connection attempt after X microseconds
> > and try another password.
>
> Not a waste unless the caller isn't going to allow for missing a valid
> password after X+1 microseconds that was late due to network latency,
> and CPU scheduling. This isn't a real time system. Even halfing the
> number of password attempts doubles the time required to search a
> particular pattern space. Double is good. It's a tried and true method
> used by security systems around the world. Another tried and true
> approach is to deny a client for a period (10 seconds?) if they enter
> the same wrong password three times in a row. It really puts a wrench
> in the gears for any brute force strategy.
I fully agree with this.
> But again, I would still prefer to avoid username/password entirely if
> security is a real concern. SSL certificates, Kerberos tokens, or
> operating system credentials (passed over UNIX sockets) appeal to me
> much more.
Sure, but I don't feel that means we should rule out adding in this
basic functionality for the username/password system that I expect we'll
support indefinitely.
Thanks,
Stephen