Re: [HACKERS] Some thoughts about SCRAM implementation - Mailing list pgsql-hackers
| From | Magnus Hagander |
|---|---|
| Subject | Re: [HACKERS] Some thoughts about SCRAM implementation |
| Date | |
| Msg-id | CABUevEwJO6QNmZVzARPf-nePv07ne1R=o73VQ2Oq6cn_+beJ_w@mail.gmail.com Whole thread Raw |
| In response to | Re: [HACKERS] Some thoughts about SCRAM implementation (Bruce Momjian <bruce@momjian.us>) |
| Responses |
Re: [HACKERS] Some thoughts about SCRAM implementation
(Heikki Linnakangas <hlinnaka@iki.fi>)
|
| List | pgsql-hackers |
On Wed, Apr 12, 2017 at 3:25 AM, Bruce Momjian <bruce@momjian.us> wrote:
-- On Tue, Apr 11, 2017 at 08:58:30PM -0400, Stephen Frost wrote:
> > > But just a bit more is needed to make it really a big announcement and
> > > provide real value to (I guess, mostly but very interesting) enterprise
> > > customers, for which MITM and impersonating are big things. The good news is
> > > that adding channel binding is like inverse Paretto: a 20% of extra effort
> > > (I bet significantly less) leads to 80% improvement.
> >
> > I don't see why channel binding is a big deal for enterprises because I
> > assume they are already using SSL:
>
> Channel binding should be used with SSL to ensure that there is no
> man-in-the-middle attack being performed. It's necessary when the
> end-points aren't performing full, mutual, certificate-based
> verification.
And which enterprises are using SSL without certificates? And I thought
channel binding required certificates anyway, e.g.:
https://en.wikipedia.org/wiki/Salted_Challenge_Response_ Authentication_Mechanism# Channel_binding
For instance, for the tls-server-end-point channel binding, it is the
server's TLS certificate.
AFAIK it does require the TLS certifificates, but it does not require TLS certificate *validation*. You can use channel binding with just self-signed certs.
That said, I stand by my comment that I don't think it's the enterprises that need or want the channel binding. If they care about it, they have already put certificate validation in place, and it won't buy them anything.
Because channel binding also only secures the authentication (SCRAM), not the actual contents and commands that are then sent across the channel, AFAIK?
> > I think the big win for SCRAM is the inability to replay md5 packets
> > after recording 16k sessions (salt was only 32-bit, so a 50% chance of
> > replay after 16 sessions), and storage of SHA256 hashes instead of MD5
> > in pg_authid, though the value of that is mostly a check-box item
> > because collisions are not a problem for the way we use MD5.
>
> There are a lot of wins to having SCRAM implemented. I disagree
> strongly that securing PG from attacks based on latent information
> gathering (backups which include pg_authid) is just a "check-box" item.
Well, they have the entire backup so I don't think cracking the password
is a huge win, though the password does potentially give them access to
future data. And it prevents them from reusing the password on another
server, but _again_, I still think the big win is to prevent replay
after 16k packets are sniffed.
In particular in multi-installation systems, it's quite likely that people at least use the same password across multiple postgres instances for example and it would help against those.
It would also help against somebody who stole a backup, and then wants to use that hash to log into the production system and *modify* things. From the backup they can read all the data, but they can't modify anything -- but with a replayable hash, they can connect and modify data. If the superuser has a password they can also use that password to escalate to OS level privileges.
I think these are both big wins. And both of them more important than channel binding.
pgsql-hackers by date: