It shouldn't break anything, i did test this with a 4.0 database and had no trouble at all.
Did you see something going wrong Chiradeep? Cheers, Hugo Sent from my iPhone On 30 okt. 2012, at 21:10, "Wido den Hollander" <w...@widodh.nl> wrote: > > > On 30-10-12 19:50, Chiradeep Vittal wrote: >> This probably breaks upgrade from 4.0. I would revert this until we find a >> solution that does not break upgrades. > > Does it? As long as you don't enable this component it won't do a thing? > > Wido > >> >> On 10/30/12 5:16 AM, "Hugo Trippaers" <htrippa...@schubergphilis.com> >> wrote: >> >>> Hey all, >>> >>> I just pushed some changes to the master branch. This is change based on >>> some security requirements that we have for storing passwords and hashes. >>> The commit is here >>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commi >>> t;h=bd58ceccd8d08a2484384a7eef6ef3c681a1e188 >>> >>> The main goal of this change was to add a new authenticator that uses the >>> SHA256 algorithm and uses a salt. This is now implemented, but to get it >>> working I needed to make a few changes to how encryption was done. >>> >>> I've tested with new code with an existing database and verified that >>> users can be created, can be updated (including passwords) and that they >>> can login on the UI without any changes to the database. The default >>> authenticator is still set to the MD5Authenticator. >>> >>> For people that want to use the new authenticator, just change the >>> components.xml.in and add the following line '<adapter name="SHA256SALT" >>> class="com.cloud.server.auth.SHA256SaltedUserAuthenticator">' to >>> UserAuthenticator. Note that this prevent any existing users for logging >>> in as their passwords will be incorrect with the new authenticator. >>> >>> Reference: http://crackstation.net/hashing-security.htm >>> >>> Cheers, >>> >>> Hugo >>> >>> Below the text of the commit for reference: >>> >>> The authenticators now have an encode function that cloudstack will use >>> to encode the user supplied password before storing it in the database. >>> This makes it easier to add other authenticators with other hashing >>> algorithms. The requires a two step approach to creating the admin >>> account at first start as the authenticators are only present in the >>> management-server component locator. >>> >>> The SHA256 salted authenticator make use of this new system and adds a >>> hashing algorithm based on SHA256 with a salt. This type of hash is far >>> less susceptible to rainbow table attacks. >>> >>> To make use of these new features the users password will be sent over >>> the wire just as he typed it and it will be transformed into a hash on >>> the server and compared with the stored password. This means that the >>> hash will not go over the wire anymore. >>> >>> The default authenticator in components.xml is still set to md5 for >>> backwards compatibility. For new installations the sha256 could be >>> enabled. >>
