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.
