cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jessica Tomechak <>
Subject Re: Review Request: Make SHA256Salt the default password encoding and authentication mechanism for cloudstack
Date Tue, 26 Mar 2013 20:27:24 GMT
I have opened that Doc bug for you, and added you to the bug as a Watcher.

Jessica T.

On Thu, Mar 21, 2013 at 1:27 AM, Vijayendra Bhamidipati <> wrote:

> Hi Prasanna,
> True, as of now the mechanism isn't configurable via the UI. The rationale
> was that the encoding and authentication choices are seldom changed once
> put in place, and that it would be better to not expose this as a
> configurable option via the UI. The list properties introduced must be
> documented as part of a doc bug associated with this change - I'll log one
> for this on jira if it isn't already there, we should have it documented in
> the admin guide.
> Earlier the client was required to md5 hash the password and send it over
> in applicable API calls, but since this was recently changed so that the
> client is now expected to pass the clear text password (which would be best
> passed using https and thus leveraging the encryption mechanism that the
> SSL handshake chooses, to protect against on the wire snooping), a cipher
> needn't be applied anymore on the client side, so it doesn't need to know
> about an encoding mechanism or ordering. The api signing process will stay
> the same since the signature generated would basically be determined by the
> supplied secret/api key pair as long as the other parameters stay the
> same.. the signing is independent of this change..
> I didn't put in an API call to list the authenticators'/encoders' current
> ordering given the above situation.. any idea of other uses of having APIs
> to retrieve these two lists?? I can put them in if they'll be useful..
> If adding a new adapter, these would be a few tests to carry out:
> 1. Keep the lists as is, and verify that encoding/authentication work as
> expected.
> 2. Add the new bean id of the new adapter to the lists.
> 3. Make the new bean id the first in the encoder list, restart the mgmt
> server, add a user, and verify by select password from cloud.user; for that
> user, that the password was generated using this new encoding adapter.
> 4. Next, if the same class implements both the encoder and authenticator,
> put the same bean id anywhere in the authenticator list, and if a different
> class implements the authenticator, put that new bean id in the
> authenticator list, and restart the mgmt server. A login of the new user
> should succeed eventually when it gets authenticated by the new adapter.
> 5. Next, remove the bean from the authenticator list, restart the mgmt
> server, and retry the user login, and it should fail.
> Regards,
> Vijay
> ________________________________________
> From: [] On
> Behalf Of prasanna []
> Sent: Wednesday, March 20, 2013 10:09 PM
> To:
> Subject: Re: Review Request: Make SHA256Salt the default password encoding
> and authentication mechanism for cloudstack
> On 20 March 2013 23:56, Vijayendra Bhamidipati
> <> wrote:
> > Hi Chip, Prasanna,
> >
> > Yes, the change is pretty straightforward, the reasoning is to make
> default password encoding more secure because the SHA256salted
> authenticator recently added by Hugo salts the passwords while the existing
> MD5 authenticator doesn't, and is the default. This change gives the CS
> admin the flexibility to choose the ordering of the
> encoders/authenticators. No new authenticator/encoder classes needed to be
> added, the existing ones are simply used better.
> >
> > Upgrade scenarios were considered and these changes will have no effect
> on upgrades. Only new users and updated users will have their passwords
> encoded by the first valid encoder in the UserPasswordEncoder list.
> Existing users will still get authenticated as before since authentication
> passes through all the authenticators available in the UserAuthenticator
> list until one of them succeeds or all fail.
> >
> Thanks Vijay, I'm just wondering how does someone not dealing with the
> UI know the auth mechanism to use? When login happens, when account
> creation happens, or when api signing happens (unaffected?)? Is there
> an API call that lists the authenticators in use on the deployment? So
> the appropriate cipher can be applied at client side?
> Also - could you list out a few tests that can be taken up to ensure
> the feature is smoke tested. By that I mean - tests that will ensure
> this feature isn't broken say when a new authenticator is used. I'm
> looking to put them down as marvin tests.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message