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.<div><br></div><div>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.</div>
<div><br></div><div><br><div><br><div class="gmail_quote">On Wed, Mar 2, 2011 at 5:17 PM, Ed Leafe <span dir="ltr"><<a href="mailto:ed@leafe.com">ed@leafe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">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 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)<br>

<br>
</div>        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.<br>

<font color="#888888"><br>
<br>
-- Ed Leafe<br>
<br>
<br>
<br>
</font></blockquote></div><br></div></div>