incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vijayendra Bhamidipati <vijayendra.bhamidip...@citrix.com>
Subject RE: Query regarding where to store encryption keys
Date Wed, 20 Jun 2012 21:04:29 GMT
Hi John!

Please see inline..

-----Original Message-----
From: John Kinsella [mailto:jlk@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

Mime
View raw message