Hi Team, This is with reference to bug CS-15151 (http://bugs.cloudstack.org/browse/CS-15151). I have some questions and it would be great if you could share your knowledge and suggestions.
We have a need to store credentials required to login to vCenter, so that that cloudstack management server can log in and talk to it. We store these credentials in the cloud.cluster_details table. Similarly, we also need to store the username/password required to login to a Nexus 1000v virtual supervisor module, and we store that password in the cloud.virtual_supervisor_module table. Currently, these passwords are stored in clear text, which is not desirable. Since we need to be able to reconstruct/retrieve the password within the management server, we cannot simply store the hash(salt + password) in the database. We can do that only when the user provides the password each time, so that we can check the hash of the salt (which we should be generating separately for each password to make rainbow attacks tougher) + password against the hash stored in the tables. It looks like there are two ways to go about implementing a solution - encryption, or secret sharing. If we encrypt the password using a key (that is probably best autogenerated like a salt), we can use that key to decrypt the password each time we need to use that password to login to the Nexus VSM or vCenter. But, storing that key in the same database where the encrypted passwords reside would defeat the purpose of encryption. So, how best to store these encryption keys for passwords? Does it help to store them in a separate schema? Or a totally different database on some other server and make it an option to the mgmt server installer to create this new db on a new server? And where do we store the credentials to login to that db server?? How do databases get stolen in the first place? What can anyone do if the db root password is compromised? Is there a concept of a "hidden table" in MySQL? Something that can only be viewed by some one privileged user or role and nobody else, and never gets exported by standard export tools? Even if such an option exists, it probably still won't help since we cannot afford to lose encryption keys during db migration. I'm just thinking aloud here. The second option, generating secret shares from passwords, relies on hiding the algorithm that we use to generate secret shares from some data. Since cloudstack code is opensource, two ways we could make this secure would be 1) to have a (n, n) secret key generation scheme, so that all n shares are required to reconstruct the password, and we store n-1 shares on the db, and store the 1 remaining share somewhere really secure. Unfortunately this again boils down to an encryption key model. In our case we could have n=2. 2) to allow the customer to plugin her own secret share generation algorithm, but I feel that in itself could be a potential security risk, unless we sandbox it in some robust way. It would be great if you could provide your views. This problem looks byzantine and I don't know if it has a simple/elegant solution. Regards, Vijay
