[
https://issues.apache.org/jira/browse/VCL-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023672#comment-16023672
]
ASF subversion and git services commented on VCL-1045:
------------------------------------------------------
Commit 1796099 from [~jfthomps] in branch 'vcl/trunk'
[ https://svn.apache.org/r1796099 ]
VCL-1045 - Method of encrypting sensitive database entries
addomain.php:
-added submitToggleDeleteResourceExtra: needed to be able to delete entries
from cryptsecret before deleting entries from addomain
-modified AJsaveResource and addResource: added code to encrypt password field
and set secretid field for entry corresponding to encrypted password
secrets-default.php:
-changed description for $cryptkey to generate a 32 byte string instead of 16
-removed $cryptiv: this should be random for every encrypted piece of data
utils.php:
-moved require_once for phpseclib files to initGlobals and only if needed
-modified initGlobals: added check for existance of openssl_encrypt function;
if exists, set USE_PHPSECLIB to 0 and base64 decode $cryptkey, otherwise,
require_once needed files and set USE_PHPSECLIB to 1; set global $ivsize to 16
-added checkCryptkey
-modified encryptData: made more generic; accepts $cryptkey as an argument,
randomly generates $iv each call, changed cypher to be 256 bit, if encryption
fails, return NULL, prepend $iv to encrypted data before base64 encoding it
-modified decryptDAta: made more generic; accepts $cryptkey as an argument,
splits base64 decoded data in to $iv and $cryptdata, changed cypher to be 256
bit, return false if decryption failes
-added encryptDBdata
-added decryptSecret
-added getSecretID
-added deleteSecrets
-added getCryptKeyID
-added encryptSecret
-added encryptSecrets
-modified getADdomains: added secretid to returned data
-modified addContinuationsEntry: pulled in $cryptkey global; pass $cryptkey to
encryptData
-modified getContinuationsData: pulled in $cryptkey global; pass $cryptkey to
decryptData
-modified xmlrpccall: added registration for XMLRPCupdateSecrets
xmlrpcWrappers.php: added XMLRPCupdateSecrets
> 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)
