Skip site navigation (1) Skip section navigation (2)

Re: RADIUS authentication

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RADIUS authentication
Date: 2010-01-24 15:56:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2010/1/24 Magnus Hagander <magnus(at)hagander(dot)net>:
> 2010/1/20 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> As Tom pointed out, it is fundamentally same.
>> The matter is this random() invocation is the first time after
>> initialization of random seed by srandom(). It means an external observer
>> can estimate the random value uniquely using pid and startup time.
>> In other representation, the "random" value is the result of function
>> which takes arguments of pid and startup time, without random factor.
>>  for (i = 0; i<  RADIUS_VECTOR_LENGTH; i++)
>>      packet->vector[i] = f(getpid(), port->SessionStartTime, i);
>> One idea is to modify the logic to set up random seed in BackendRun().
>> In most of UNIX-like operating system, we can use /dev/random as a random
>> seed which is well randomized.
>> It seems to me PostmasterRandom() is a right place to set random seed,
>> and we can inject a block something like #ifdef HAVE_DEV_RANDOM ...
>> Instead of such kind of efforts, we can also document that PostgreSQL and
>> RADIUS server should have communication using enough secure connection
>> explicitly. IMO, it will cover most of use cases.
> There is one more option here - use OpenSSL if available. It has
> functions for secure random number generations
> (  That seems easy
> enough when OpenSSL is available.
> The question then becomes what do we do if we don't have OpenSSL
> available? Do we document that it's not secure, or refuse to run it?
> I'd vote for document it.. If you don't have SSL enabled, then you
> clearly don't use SSL for the libpq connection, which means the
> password goes in cleartext in that stream...

Updated patch attached.

 Magnus Hagander

Attachment: radius.patch
Description: application/octet-stream (19.5 KB)

In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2010-01-24 16:00:06
Subject: Re: handling contrib directories as modules not shared libraries
Previous:From: Teodor SigaevDate: 2010-01-24 15:55:04
Subject: Re: Red-black tree for GIN

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group