Re: Password identifiers, protocol aging and SCRAM protocol - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Password identifiers, protocol aging and SCRAM protocol
Date
Msg-id 8d025718-e579-261b-9513-a53265fd2932@iki.fi
Whole thread Raw
In response to Re: Password identifiers, protocol aging and SCRAM protocol  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Password identifiers, protocol aging and SCRAM protocol
List pgsql-hackers
On 09/27/2016 04:19 PM, Michael Paquier wrote:
> On Tue, Sep 27, 2016 at 9:01 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> * A source of random values. This currently uses PostmasterRandom()
>> similarly to how the MD5 salt is generated, in the server, but plain old
>> random() in the client. If built with OpenSSL, we should probably use
>> RAND_bytes(). But what if the client is built without OpenSSL? I believe the
>> protocol doesn't require cryptographically strong randomness for the nonces,
>> i.e. it's OK if they're predictable, but they should be different for each
>> session.
>
> And what if we just replace PostmasterRandom()? pgcrypto is a useful
> source of inspiration here. If the server is built with OpenSSL we use
> RAND_bytes all the time. If not, let's use /dev/urandom. If urandom is
> not there, we fallback to /dev/random. For WIN32, there is
> CryptGenRandom(). This could just be done as an independent patch with
> a routine in src/common/ for example to allow both frontend and
> backend to use it.

Yeah, if built with OpenSSL, we probably should just always use 
RAND_bytes(). Without OpenSSL, we have to think a bit harder.

The server-side code in the patch is probably good enough. After all, we 
use the same mechanism for the MD5 salt today.

The libpq-side is not. Just calling random() won't do. We haven't needed 
for random numbers in libpq before, but now we do. Is the pgcrypto 
solution portable enough that we can use it in libpq?

> Do you think that this is a requirement for this
> patch? I think not really for the first shot.

We need something for libpq. We can't just call random(), as that's not 
random unless you also do srandom(), and we don't want to do that 
because the application might have a different idea of what the seed 
should be.

- Heikki




pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: pgbench more operators & functions
Next
From: Michael Paquier
Date:
Subject: Re: Password identifiers, protocol aging and SCRAM protocol