Re: [HACKERS] Some thoughts about SCRAM implementation
От | Álvaro Hernández Tortosa |
---|---|
Тема | Re: [HACKERS] Some thoughts about SCRAM implementation |
Дата | |
Msg-id | 96912a79-a7a8-14bb-bd88-9044f1af637c@8kdata.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Some thoughts about SCRAM implementation (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 12/04/17 18:09, Tom Lane wrote: > Heikki Linnakangas <hlinnaka@iki.fi> writes: >> On 04/12/2017 06:26 PM, Bruce Momjian wrote: >>> How does it do that? >> Good question, crypto magic? I don't know the details, but the basic >> idea is that you extract a blob of data that uniquely identifies the TLS >> connection. Using some OpenSSL functions, in this case. I think it's a >> hash of some of the TLS handshake messages that were used when the TLS >> connection was established (that's what "tls-unique" means). That data >> is then incorporated in the hash calculations of the SCRAM >> authentication. If the client and the server are not speaking over the >> same TLS connection, they will use different values for the TLS data, >> and the SCRAM computations will not match, and you get an authentication >> failure. I believe the above is not correct. Channel binding data is *not* used for any hash computations. It is simply a byte array that is received as an extra user parameter, and the server then gets it by its own way (its own TLS data) and do a byte comparison. That's what the RFCs say about it. > ... which the user can't tell apart from having fat-fingered the password, > I suppose? Doesn't sound terribly friendly. A report of a certificate > mismatch is far more likely to lead people to realize there's a MITM. So given what I said before, that won't happen. Indeed, SCRAM RFC contains a specific error code for this: "channel-bindings-dont-match". Álvaro -- Álvaro Hernández Tortosa ----------- <8K>data
В списке pgsql-hackers по дате отправления: