Hi John! Please see inline..
-----Original Message----- From: John Kinsella [mailto:j...@stratosec.co] Sent: Wednesday, June 20, 2012 12:47 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Query regarding where to store encryption keys (sounds like Kishan has a direct answer, but I'm sending this in case it's of value from an appsec POV) On Jun 20, 2012, at 12:15 PM, Vijayendra Bhamidipati wrote: > 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. (I can't view that bug, not sure about others) >> I didn't notice it was private - will be careful in future. > 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? A DB is usually going to get compromised via one of two days: * Somebody figures out a vulnerability to get the app to provide data it wasn't designed to provide - either a page which displays data from the DB can be manipulated to show records or fields other than what the developer intended, or with something like a multi-stage attack: Malicious user finds SQL injection weakness, uses that to gain administrative access to the app, and then uses that to read data from the system * Malicious user is able to copy the db files: this can be the result of gaining administrative access to the host and simply copying the files, or more creative methods, such as finding a vulnerability in a web app that allows them to download the db files. Think: somewhere in an app you display a user's photo that they've uploaded, without renaming the file. If uploaded filename was "../../../../../var/lib/mysql/mysql/cloud/user.frm" and for some reason the application didn't sanitize the filename, things could get Interesting... >> Those are interesting scenarios, thanks for the info! Either way, my recommendation would be to encrypt, but keep the crypto key out of the DB (I believe this is what CS does): either in a config file on the host, or maybe in time support keeping the encryption key on a separate host or in an appliance designed to secure and manage those encryption keys. This way, a malicious user has to be able to access the encrypted data in the db, and also the key on the filesystem or on a separate host. >> yes, I think CS already do this like Kishan pointed out - I'll go through >> that and work with Kishan to put in the necessary fix. KISS works great for security-related issues. When you start trying to come up with custom ways of doing things, you risk a chance of not doing it right and somebody else finding a vulnerability they can leverage. >> Will keep this in mind :) John >> Thanks a ton for the pointers/info! Regards, Vijay
