Josh Thompson created VCL-1045:
----------------------------------
Summary: Method of encrypting sensitive database entries
Key: VCL-1045
URL: https://issues.apache.org/jira/browse/VCL-1045
Project: VCL
Issue Type: Improvement
Components: vcld (backend), web gui (frontend)
Reporter: Josh Thompson
Fix For: 2.5
The new AD Domain code requires that a password be stored in the database.
There is an optional component of VMware support that requires that a password
be stored in the database as well. Aaron Coburn developed a way for the VMware
piece to be encrypted. Having a generic method for securely storing passwords
in the database that is simple to configure is really needed moving forward.
This issue outlines an automatically configured secure method of storing
passwords.
3 new tables are required:
*cryptkey*
* id
* hostid - managementnode.id or webserver.id
* hosttype - managementnode or web
* pubkey - public key from a public/private key pair
*cryptsecret*
* id
* cryptkeyid - reference to cryptkey.id
* secretid - id of this secret
* cryptsecret - encrypted secret key
*webserver*
* id
* host - hostname or IP address of web server
* checkin - datetime updated each time a user logs in (rather than updating
every page load)
Any table having a password (or similar) field will need to have that field,
which will be encrypted using a secret key, and a secretid field that
corresponds to cryptsecret.secretid.
h2. Populating cryptkey table for management nodes
When vcld starts, it should check for having an entry in cryptkey. If it
doesn't, it will generate a public/private key pair, store the private key
locally, store the public key in cryptkey, and call an XMLRPC API method a web
server to generate any needed entries in cryptsecret (more on this later).
h2. Populating cryptkey table for web servers
Either as part of installation (via install script or viewing testsetup.php) or
as a check at some event (page load, user log in, etc), a web server will check
for having an entry in cryptkey. If it doesn't, it will generate a
public/private key pair, store the private key locally, and store the public
key in cryptkey. At this point, it wouldn't have any cryptsecret entries.
Another web server or a management node would need to detect this and populate
them. Alternatively, vcld --setup could be used to populate this. Another
option is to attempt calling the XMLRPC API at the direct hostname or IP
address of another web server.
h2. Using cryptsecret
Any entry needing encrypting will need an additional field added to reference
the cryptsecret table. When a new entry is created, a new secret key must be
generated by the system (vcld or web) creating the entry. The field is
encrypted with this secret key. The secret key is then encrypted with every
systems' cryptkey.pubkey with the encrypted values written to the cryptsecret
table. This allows any system to be able to decrypt the secret key and then
decrypt the field. When a field needs to be read, the encrypted secret is read
from the cryptsecret table, then decrypted using the system's private key that
corresponds to the public key in the cryptkey table, then the field can be
decrypted. When a value needs to be updated, the secret key is determined as
when reading, then used to encrypt the new value. As an example, if a new
record is added to the addomain table, the password field must be encrytped. A
new secret key is generated by the web code. Then, the password is encrypted
with that key. The encrypted password is written to the database. The secret
key is encrypted with each cryptkey.publkey and each encrypted secret key is
written to the cryptsecret table.
h2. XMLRPC API function to generate new keys
An XMLRPC API function will be created named XMLRPCpopulateCryptSecrets. This
function will look for any management nodes or web servers that have entries in
cryptkey but have missing entries in cryptsecret. Entries will then be
generated in cryptsecret.
h2. Cryptographic algorithms
Symmetric and asymmetric algorithms along with key lengths are yet to be
determined. Code should be written such that these would be fairly easy to
update.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
