> -----Original Message----- > From: Kishan Kavala [mailto:kishan.kav...@citrix.com] > Sent: Thursday, 16 May 2013 1:24 PM > To: dev@cloudstack.apache.org > Subject: RE: [ACS41] Current blocker status > > > > > -----Original Message----- > > From: Prasanna Santhanam [mailto:t...@apache.org] > > Sent: Thursday, 16 May 2013 12:39 PM > > To: dev@cloudstack.apache.org > > Subject: Re: [ACS41] Current blocker status > > > > On Thu, May 16, 2013 at 11:51:06AM +0530, Prasanna Santhanam wrote: > > > On Wed, May 15, 2013 at 03:07:41PM -0700, Animesh Chaturvedi wrote: > > > > > CLOUDSTACK-2516 > > > > > Create User API compability broken now > > > > > > > > > > Nobody has taken this on yet. > > > > [Animesh>] I will update the JIRA ticket, looks like this was > > > > changed by Kishan to use clear text password. I think > > > > functionality wise it will still work but will cause double > > > > encryption. We will have to wait for Kishan to respond on this. > > > > > > I think Kishan only added regions support. That piece of code has > > > existed for a long time. I'm guessing something in the order of > > > authenticators is going wrong although componentContext.xml.in is > > > using MD5 auth first. Investigating .. > > > > > > > This change happened when the authenticators were moved in to use > > adapters. That change was a logical one to support multiple Auth > > mechanisms. Hugo made the change in (bd58cecc) and it is the right way > > to do it. > > > > Prior to Hugo's fix the MD5 authenticator,although called so, would > > only do a plaintext match of passwords with the database. Also the > > createUser() would simply persist the password coming in over with > > wire into the db. Thereby it assumed tht the passwd would be > > pre-encoded as MD5 at the client. > > > > So, why did MD5 passwds get into the DB at all? > > The API documentation asks that the client send in a md5 hashed > > password and our ui script (account.js, sharedFunction.js) is hashing > > the passwords into md5. > > > > There was probably a reason behind this. I'm not sure: Here's the > > comment indicating the change: > > > > """ > > // Will: The MD5Authenticator is now a straight pass-through > > comparison of the // the passwords because we will not assume that the > > password passed in has // already been MD5 hashed. I am keeping the > > above code in case this requirement changes // or people need examples > > of how to MD5 hash passwords in java. > > if (!user.getPassword().equals(password)) { > > return false > > """ > > > > After Hugo's fix the MD5 Authenticator (the default authenticator) now > > _actually_ does the encoding and not depend on the client. But the UI > > code still seems to exist and double encodes the md5 entry in the form. > > > > So the fix should be > > - UI removes the double hashing when account creation happens. > > - Fix the API doc to ask user to send in plaintext password and allow > > to act based on authenticator configured in componentsContext.xml > > > > As an aside: > > Hugo, the SHA256 authenticator you introduced seems to have been > > removed from the componentContexts. Do you want to include it back, > > commented? > > > > Thanks, > > -- > > Prasanna., > > > > ------------------------ > > Powered by BigRock.com > > Agree with Prasanna. Authenticator changes were introduced via commit > bd58cecc prior to Regions related changes. > > Couple of ways to fix this now: > 1. UI/client sends plain text as suggested by Prasanna along with api doc > fix. > This would mean breaking backward compatibility but it's the clean way. > 2. Other option is to add PlainTextAuthenticator in ComponentContext to > support existing clients. Master already has these changes. >
I've submitted patch [1] to add PlainTextAuthenticator. This will solve the backward compatibility issue. - Recommended option is for clients to send plain text instead of MD5 after upgrading to 4.1. - For those who do not want to change their client, componentContext.xml has to be changed to use PlainTextAuthenticator as default authenticator. Following scenario should be avoided: - Client sends MD5 hash and default authenticator is MD5UserAuthenticator. Password stored in DB will be MD5 hashed twice. This will work as long client keeps sending MD5 hash and default authenticator is MD5UserAuthenticator. If the default authenticator is changed or if client changes to send plain text, existing users won't be able to login. Things will get even more complex when SHA256 becomes the default in 4.2. [1] https://reviews.apache.org/r/11194/
