I was made aware of this commit to the PostgreSQL sources: commit 0d1ecd6300191a450978ca2fcd12bbbb7c5e65e6 Author: Tom Lane <tgl () sss pgh pa us> Date: Wed Mar 27 18:50:21 2013 -0400 Reset OpenSSL randomness state in each postmaster child process. Previously, if the postmaster initialized OpenSSL's PRNG (which it will do when ssl=on in postgresql.conf), the same pseudo-random state would be inherited by each forked child process. The problem is masked to a considerable extent if the incoming connection uses SSL encryption, but when it does not, identical pseudo-random state is made available to functions like contrib/pgcrypto. The process's PID does get mixed into any requested random output, but on most systems that still only results in 32K or so distinct random sequences available across all Postgres sessions. This might allow an attacker who has database access to guess the results of "secure" operations happening in another session. To fix, forcibly reset the PRNG after fork(). Each child process that has need for random numbers from OpenSSL's generator will thereby be forced to go through OpenSSL's normal initialization sequence, which should provide much greater variability of the sequences. There are other ways we might do this that would be slightly cheaper, but this approach seems the most future-proof against SSL-related code changes. This has been assigned CVE-2013-1900, but since the issue and the patch have already been publicized on pgsql-hackers, there's no point in trying to hide this commit. Back-patch to all supported branches. Marko Kreen I believe it is wrong to fix this in PostgreSQL. Rather, this is a bug in the OpenSSL fork protection code. It should either install a fork hook, or reseed the PRNG from /dev/urandom if a PID change is detected.