Why go to all this effort to promote bad code, when writing good code is just as easy?  This is a fairly trivial fix we're talking about, probably comparable to the effort of running strace.<div><div><br></div><div>Anyway, my focus is on users that don't want you setting passwords into their boxes (especially after reading this thread).  Is bypassing password generation in scope, or should I open a new bug?<br>
<div><br></div><div><div><div><br><br><div class="gmail_quote">On Wed, Mar 2, 2011 at 5:57 PM, Mark Washenberger <span dir="ltr"><<a href="mailto:mark.washenberger@rackspace.com">mark.washenberger@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Each time I call random.seed() on my box, it grabs another 256 bits from /dev/urandom (verified by strace).<br>
<br>
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.<br>
<div class="im"><br>
"Justin Santa Barbara" <<a href="mailto:justin@fathomdb.com">justin@fathomdb.com</a>> said:<br>
<br>
> _______________________________________________<br>
> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div><div><div></div><div class="h5">> We should be "secure out of the box", and not require the user to change<br>
> their password or manually lock down SSH to disable password auth.<br>
><br>
> A secure password would still be just as readable: I was thinking we'd use<br>
> the secure bytes to generate a readable password (either using them as a<br>
> seed or e.g. by mapping 5 bits at a time).  By using only 5 bits, we can<br>
> skip some of the trickier letter pairs e.g. 1/I or 0/O.<br>
><br>
><br>
><br>
> On Wed, Mar 2, 2011 at 5:17 PM, Ed Leafe <<a href="mailto:ed@leafe.com">ed@leafe.com</a>> wrote:<br>
><br>
>> On Mar 2, 2011, at 8:01 PM, Justin Santa Barbara wrote:<br>
>><br>
>> > Also, I know security through obscurity isn't really security, but if<br>
>> we're open source, I think we must have "strong" password generation,<br>
>> whatever may or may not have been the case in the past.  I suggest beefing<br>
>> up the generate_password function to make use of os.urandom (which I know<br>
>> isn't perfect either, but is probably secure enough for anyone willing to<br>
>> rely on a password)<br>
>><br>
>>         The general process (at least in Rackspace Cloud Servers) is to<br>
>> create an initial root password which we then display for the instance<br>
>> owner; he/she can then shell in and change it to whatever they like. So I<br>
>> think that at best the os.urandom generator should be an option, with the<br>
>> less secure but easier to communicate password scheme also available.<br>
>><br>
>><br>
>> -- Ed Leafe<br>
>><br>
>><br>
>><br>
>><br>
><br>
<br>
<br>
</div></div></blockquote></div><br></div></div></div></div></div>