Changing the Default Password Encryption
55
• VPN password
• User API secret key
• VNC password
CloudPlatform uses the Java Simplified Encryption (JASYPT) library. The data values are encrypted
and decrypted using a database secret key, which is stored in one of CloudPlatform’s internal
properties files along with the database password. The other encrypted values listed above, such as
SSH keys, are in the CloudPlatform internal database.
Of course, the database secret key itself can not be stored in the open – it must be encrypted. How
then does CloudPlatform read it? A second secret key must be provided from an external source
during Management Server startup. This key can be provided in one of two ways: loaded from a file or
provided by the CloudPlatform administrator. The CloudPlatform database has a configuration setting
that lets it know which of these methods will be used. If the encryption type is set to “file,” the key must
be in a file in a known location. If the encryption type is set to “web,” the administrator runs the utility
com.cloud.utils.crypt.EncryptionSecretKeySender, which relays the key to the Management Server
over a known port.
The encryption type, database secret key, and Management Server secret key are set during
CloudPlatform installation. They are all parameters to the CloudPlatform database setup script
(cloudstack-setup-databases). The default values are file, password, and password. It is, of course,
highly recommended that you change these to more secure keys.
5.4.6. Changing the Default Password Encryption
Passwords are encoded when creating or updating users. The default preferred encoder is SHA256.
It is more secure than MD5 hashing, which was used in CloudPlatform 3.x. If you take no action to
customize password encryption and authentication, SHA256 Salt will be used.
If you prefer a different authentication mechanism, CloudPlatform provides a way for you to determine
the default encoding and authentication mechanism for admin and user logins. Two configurable lists
are provided: userPasswordEncoders and userAuthenticators. userPasswordEncoders allow you
to configure the order of preference for encoding passwords, and userAuthenticator allows you to
configure the order in which authentication schemes are invoked to validate user passwords.
The following method determines what encoding scheme is used to encode the password supplied
during user creation or modification.
When a new user is created, the user password is encoded by using the first valid encoder
loaded as per the sequence specified in the UserPasswordEncoders property in
the ComponentContext.xml or nonossComponentContext.xml files. The order
of authentication schemes is determined by the UserAuthenticators property in
the same files. If Non-OSS components, such as VMware environments, are to be
deployed, modify the UserPasswordEncoders and UserAuthenticators lists in the
nonossComponentContext.xml file. For OSS environments, such as XenServer or KVM, modify
the ComponentContext.xml file. It is recommended to make uniform changes across both the files.
When a new authenticator or encoder is added, you can add them to this list. While doing so, ensure
that the new authenticator or encoder is specified as a bean in both the files. The administrator can
change the ordering of both these properties as desired to change the order of schemes. Modify the
following list properties available in client/tomcatconf/nonossComponentContext.xml.in or
client/tomcatconf/componentContext.xml.in as applicable, to the desired order:
<property name="UserAuthenticators">
<list>