From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: MD5 authentication needs help |
Date: | 2015-03-06 23:04:42 |
Message-ID: | 20150306230442.GB12967@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 5, 2015 at 11:15:55AM -0500, Stephen Frost wrote:
> * Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> > On Wed, Mar 4, 2015 at 05:56:25PM -0800, Josh Berkus wrote:
> > > So, are we more worried about attackers getting a copy of pg_authid, or
> > > sniffing the hash on the wire?
> >
> > Both. Stephen is more worried about pg_authid, but I am more worried
> > about sniffing.
>
> I'm also worried about both, but if the admin is worried about sniffing
> in their environment, they're much more likely to use TLS than to set up
> client side certificates, kerberos, or some other strong auth mechanism,
> simply because TLS is pretty darn easy to get working and distros set it
> up for you by default.
I think your view might be skewed. I think there many people who care
about password security who don't care to do TLS.
Also, my suggestion to use a counter for the session salt, to reduce
replay from 16k to 4 billion, has not received any comments, and it does
not break the wire protocol. I feel that is an incremental improvement
we should consider.
I think you are minimizing the downsize of your idea using X challenges
instead of 16k challenges to get in. Again, if my idea is valid, it
would be X challenges vs 4 billion challenges.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2015-03-06 23:17:20 | Re: MD5 authentication needs help |
Previous Message | Alvaro Herrera | 2015-03-06 22:57:53 | Re: alter user/role CURRENT_USER |