Date: Mon, 8 Jan 2007 10:42:12 -0800 From: Garrett Cooper <youshi10@u.washington.edu> To: freebsd-questions@freebsd.org Subject: Re: pwgen's seeding looks insecure Message-ID: <F654A761-465F-4A60-B152-573DEBF1B432@u.washington.edu> In-Reply-To: <20070108175314.27ce391f@gumby.homeunix.com> References: <20070108175314.27ce391f@gumby.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. pwgen would do better on a system with a lot more processes though, or one that's been up longer though, since PIDs increase over time. -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F654A761-465F-4A60-B152-573DEBF1B432>