Re: MD5 authentication needs help -SCRAM - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: MD5 authentication needs help -SCRAM
Date
Msg-id 54FD896A.3090904@iki.fi
Whole thread Raw
In response to Re: MD5 authentication needs help -SCRAM  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Responses Re: MD5 authentication needs help -SCRAM  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
List pgsql-hackers
Hi Abhijit, I didn't realize you were involved in the IETF process on 
SCRAM :-).

On 03/09/2015 09:21 AM, Abhijit Menon-Sen wrote:
> At 2015-03-08 12:48:44 -0700, josh@agliodbs.com wrote:
>>
>> Since SCRAM has been brought up a number of times here, I thought
>> I'd loop in the PostgreSQL contributor who is co-author of the SCRAM
>> standard to see if he has anything to say about implementing SCRAM as
>> a built-in auth method for Postgres.
>
> I think it's a good idea.

Having done some googling, SCRAM seems like a good choice to me too. 
Another one is SRP. The important difference between SRP and SCRAM is 
that in SRP, an eavesdropper cannot capture information needed to 
brute-force the password. The class of protocols that have that property 
are called Password-authenticated key agreement protocols (PAKE) [1]. 
SRP seems to be the most common one of those, although there are others.

On the face of it, it seems like PAKE protocols are superior. There is 
an IETF draft for SRP as a SASL authentication mechanism [2], and even 
some implementations of that (e.g. Cyrus-SASL), but for some reason that 
draft never became a standard and expired. Do you have any insight on 
why the IETF working group didn't choose a PAKE protocol instead of or 
in addition to SCRAM, when SCRAM was standardized?

[1] https://en.wikipedia.org/wiki/Password-authenticated_key_agreement
[2] https://tools.ietf.org/html/draft-burdis-cat-srp-sasl-08

- Heikki



pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: EvalPlanQual behaves oddly for FDW queries involving system columns
Next
From: Beena Emerson
Date:
Subject: pg_trgm Memory Allocation logic