From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | mark(at)mark(dot)mielke(dot)cc |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Weak passwords and brute force attacks |
Date: | 2006-12-05 18:06:35 |
Message-ID: | 20061205180635.GC24675@kenobi.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* mark(at)mark(dot)mielke(dot)cc (mark(at)mark(dot)mielke(dot)cc) wrote:
> On Tue, Dec 05, 2006 at 11:32:40AM -0500, Tom Lane wrote:
> > Gavin Sherry <swm(at)linuxworld(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Volkan YAZICI | 2006-12-05 18:15:14 | Re: Preserving Cluster-Wise Data |
Previous Message | Andrew Dunstan | 2006-12-05 18:06:18 | Re: Preserving Cluster-Wise Data |