2010/1/24 Magnus Hagander <mag...@hagander.net>: > 2010/1/20 KaiGai Kohei <kai...@ak.jp.nec.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. >> >> http://en.wikipedia.org/wiki//dev/random >> >> 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 > (http://www.openssl.org/docs/crypto/RAND_bytes.html). 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 Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
radius.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers