Open Stack

Yikes, I'm sorry. I didn't mean to give the impression of promoting bad code. I was coming at it from a simplicity perspective because I mistakenly thought my approach was cryptographically equivalent, assuming a case where the user does not want to skip password injection.

To your main point, I share your desire to be able to turn off password injection during instance creation. (For clarity, I'm assuming that your preference is to create the vm with no root password and only ssh keys as a means of access.) I guess the main problem with this is that it isn't in the 1.[01] spec so we'd need to agree on a sensible way of adding it to the api.

Does anyone know if it would create any compatibility problems to support an optional "disable_admin_pass": "True" attribute to the /servers POST request? Are there any reasons other than compatibility to require an adminPass to always be set?

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

> 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.
> 
> 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?
> 
> 
> 
> On Wed, Mar 2, 2011 at 5:57 PM, Mark Washenberger <
> mark.washenberger at rackspace.com> wrote:
> 
>> 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
>> >>
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>