cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <Chiradeep.Vit...@citrix.com>
Subject Re: [ACS41] Current blocker status
Date Thu, 16 May 2013 19:12:14 GMT
See this discussion

http://s.apache.org/gW

On 5/16/13 12:53 AM, "Kishan Kavala" <Kishan.Kavala@citrix.com> wrote:

>
>
>> -----Original Message-----
>> From: Prasanna Santhanam [mailto:tsp@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.
>
>


Mime
View raw message