From owner-freebsd-questions@FreeBSD.ORG Mon Jan 8 19:57:36 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61EFE16A407 for ; Mon, 8 Jan 2007 19:57:36 +0000 (UTC) (envelope-from fbsd06@mlists.homeunix.com) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by mx1.freebsd.org (Postfix) with ESMTP id 3C03913C455 for ; Mon, 8 Jan 2007 19:57:36 +0000 (UTC) (envelope-from fbsd06@mlists.homeunix.com) Received: from gumby.homeunix.com (unknown [87.81.140.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 0556351931 for ; Mon, 8 Jan 2007 14:57:34 -0500 (EST) Date: Mon, 8 Jan 2007 19:57:32 +0000 From: RW To: freebsd-questions@freebsd.org Message-ID: <20070108195732.7b4a4b2b@gumby.homeunix.com> In-Reply-To: References: <20070108175314.27ce391f@gumby.homeunix.com> X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.10.6; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: pwgen's seeding looks insecure X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2007 19:57:36 -0000 On Mon, 8 Jan 2007 10:42:12 -0800 Garrett Cooper wrote: > On Jan 8, 2007, at 9:53 AM, RW wrote: > > > Someone recently recommended sysutils/pwgen for generating user > > passwords. Out of curiosity I had a look at how it works, and I > > don't like the look of its PRNG initialization: > > > > > > #ifdef RAND48 > > srand48((time(0)<<9) ^ (getpgrp()<<15) ^ (getpid()) ^ (time(0) > > >>11)); > > #else > > srand(time(0) ^ (getpgrp() << 8) + getpid()); > > #endif > > > > > > If pwgen is called from an account creation script, time(0) can be > > inferred from timestamps, e.g. on a home-directory, so that just > > leaves > > getpid() and getpgrp(). PIDs are allocated sequentially and > > globally, so getpid() is highly predictable. I don't know much > > about getpgrp(), but from the manpage it doesn't appear to be any > > better. > > > > Unless getpgrp() is a better source of entropy than I give it credit > > for, I think this port should perhaps be marked as vulnerable. > > It's not spectacular looking at that output, but it seems like a > typical hash. > > As long as getpgrp() and getpid() don't always fall in the same > range (thus producing the same sets of numbers) and getpid() doesn't > return a multiple of getpgrp() << 8, I don't see any particular > problems with the above setup. > My concern is that an unprivileged attacker could log pids created by his own processes and virtually eliminate entropy from getpid(). I'm wondering if something similar can be done with getpgrp(). If it can then entropy may fall to a handfull of bits, and bruteforce may not be all that brutal.