[
https://issues.apache.org/jira/browse/VCL-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048299#comment-16048299
]
ASF subversion and git services commented on VCL-1045:
------------------------------------------------------
Commit 1798632 from [email protected] in branch 'vcl/trunk'
[ https://svn.apache.org/r1798632 ]
VCL-1045
Uncommented CPAN urllist config option and updated URL to cpan-rsync.perl.org.
I saw a case where the script failed without a URL configured.
> 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.
> 2 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
> * algorithm - encryption algorithm
> * algorithmoption - mode of algorithm (i.e. CBC, ECB, CTR, etc) or digest type
> * keylength - length of key in bits
> *cryptsecret*
> * id
> * cryptkeyid - reference to cryptkey.id
> * secretid - id of this secret
> * cryptsecret - encrypted secret key
> * algorithm - encryption algorithm
> * algorithmoption - mode of algorithm or digest type
> * keylength - length of key in bits
> 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 and store the public key in cryptkey.
> 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 a private key file, a cryptkeyid file, and an entry in
> cryptkey. If it doesn't, it will generate a public/private key pair, store
> the private key and cryptkey.id locally, and store the public key in
> cryptkey. At this point, if it does not share a filesystem with other web
> servers, it wouldn't have any cryptsecret entries. Another web server would
> need to detect this and populate them. Another option is to attempt calling
> an 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 web server creating the entry. The field is encrypted with
> this secret key. The secret key is then encrypted with any other web server's
> cryptkey.pubkey with the encrypted values written to the cryptsecret table.
> This allows any web server 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. After the secret has
> been decrypted, the secured field can be decrypted using that secret. When a
> value needs to be updated, the secret key is determined as when reading, then
> used to encrypt the new value.
> When a reservation is made for a node that would use a secured value, the
> cryptsecret table must be checked to ensure the management node processing
> the reservation has an entry for the secret securing the value. If not, it
> will be added at that time using the management node's cryptkey. This ensures
> management nodes only have access to secured data they need, allowing
> management nodes at different affiliation's sites to only have access to that
> affiliation's data.
> 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 any other web server's
> 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 XMLRPCcheckCryptSecrets. This
> function will accept a reservation id as an argument. It will ensure the
> management node processing the specified reservation id has all entries in
> cryptsecret needed to process the reservation. Any missing entries will be
> populated.
> h2. Cryptographic algorithms
> Encryption algorithms, algorithm modes, and key lengths are saved in both the
> cryptkey and cryptsecret tables so that future updates can easily be made.
> To start out, 256 bit AES in CBC mode should be used for symmetric
> encryption. 4096 bit RSA with SHA512 as the digest algorithm should be used
> for asymmetric encryption. Code should be written such that these would be
> fairly easy to update.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
