Open Stack

Each time I call random.seed() on my box, it grabs another 256 bits from /dev/urandom (verified by strace).

I feel like we can just rely on the old standby [random.choice(pwchars) for i in xrange(pwlength)], peppering a few random.seed() calls in periodically to skip onto a new pseudorandom loop if necessary. 

"Justin Santa Barbara" <justin at fathomdb.com> said:

> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> We should be "secure out of the box", and not require the user to change
> their password or manually lock down SSH to disable password auth.
> 
> A secure password would still be just as readable: I was thinking we'd use
> the secure bytes to generate a readable password (either using them as a
> seed or e.g. by mapping 5 bits at a time).  By using only 5 bits, we can
> skip some of the trickier letter pairs e.g. 1/I or 0/O.
> 
> 
> 
> On Wed, Mar 2, 2011 at 5:17 PM, Ed Leafe <ed at leafe.com> wrote:
> 
>> On Mar 2, 2011, at 8:01 PM, Justin Santa Barbara wrote:
>>
>> > Also, I know security through obscurity isn't really security, but if
>> we're open source, I think we must have "strong" password generation,
>> whatever may or may not have been the case in the past.  I suggest beefing
>> up the generate_password function to make use of os.urandom (which I know
>> isn't perfect either, but is probably secure enough for anyone willing to
>> rely on a password)
>>
>>         The general process (at least in Rackspace Cloud Servers) is to
>> create an initial root password which we then display for the instance
>> owner; he/she can then shell in and change it to whatever they like. So I
>> think that at best the os.urandom generator should be an option, with the
>> less secure but easier to communicate password scheme also available.
>>
>>
>> -- Ed Leafe
>>
>>
>>
>>
>