[
https://issues.apache.org/jira/browse/VCL-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023632#comment-16023632
]
ASF subversion and git services commented on VCL-1045:
------------------------------------------------------
Commit 1796097 from [~jfthomps] in branch 'vcl/trunk'
[ https://svn.apache.org/r1796097 ]
VCL-1045 - Method of encrypting sensitive database entries
updating version of phpseclib to 1.0.6
> 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)
