Skip site navigation (1)Skip section navigation (2)
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>