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 по дате отправления: