Re: Random number generation, take two

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Random number generation, take two
Date: 2016-11-30 19:20:39
Message-ID: 1301d3c8-53ee-4850-f492-7768171f5ae8@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/30/2016 09:05 PM, Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
>> On 11/30/2016 09:01 AM, Michael Paquier wrote:
>
>>> It is important that this value [nonce] be different for each
>>> authentication (see [RFC4086] for more details on how to achieve
>>> this)
>>
>> So the nonces need to be different for each session, to avoid replay
>> attacks. But they don't necessarily need to be unpredictable, they are
>> transmitted in plaintext during the authentication, anyway. If an attacker
>> can calculate them in advance, it only buys him more time, but doesn't give
>> any new information.
>>
>> If we were 100% confident on that point, we could just always use current
>> timestamp and a counter for the nonces. But I'm not that confident,
>> certainly feels better to use a stronger random number when available.
>
> Hmm, if enough internal server state leaks through the nonce (PID
> generation rate), since the generating algorithm is known, isn't it
> feasible for an attacker to predict future nonces?

Yes.

> That would make brute-force attacks practical.

For SCRAM, you still need to reverse the SHA-256 hash that's used in the
protocol. That's not practical even if you have plenty of time.

Reversing the MD5 hash used in MD5 authentication, on the other hand...
But note that this patch makes the situation better for platforms that
do have a strong random source. Currently, we always rely on random(),
but with this patch, we'll use a strong source.

> Perhaps it's enough to have a #define to enable a weak RNG to be used
> for nonces when --disable-strong-random. That way you're protected by
> default because the auth mechanism doesn't even work if you don't
> have a strong RNG, but you can enable it knowingly if you so desire.

That's overdoing it, IMHO. Any modern system will have a source of
randomness, we're in practice only talking about pademelon and similar
ancient or super-exotic systems. And --disable-strong-random is the
escape hatch for that: you can use it if you don't care, but it makes it
an explicit decision.

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-11-30 20:48:01 Re: Hash Indexes
Previous Message Tom Lane 2016-11-30 19:20:25 Re: pgbench - allow backslash continuations in \set expressions