where to store SECURITY key

[Chapoor Chapoor <ch...@gmail.com>]

Hi,

Im about to set up a web application running Tomcat.
The application will handle a simple user account information, etc.

Some data will need to be encrypted before storing it into a database.
I will use AES for encryption/decryption.

A "password" will be used as a phrase/key.


Now where can I store this key? and still have "good" security.

I dont want to store it on disk. Im thinking of having it only in memory.

I m thinking of giving the password each time Tomcat is started.
How do you force tomcat to ask a password during startup?

How do you avoid memory swapping? And is there any risk that the password is
removed from
memory even that Tomcat is running? How to avoid this?

Do you have better solutions?


Please advice,


Great thanks,
Chapoor

Re: where to store SECURITY key

[Mark Thomas <ma...@apache.org>]

Chapoor Chapoor wrote:
> Now where can I store this key? and still have "good" security.
Good is a relative term. You need to do a threat assessment to 
identify your threats and then mitigate them until the risk level 
reaches an acceptable level. I would be *very* surprised if this 
included not having the password on disk.

> I dont want to store it on disk. Im thinking of having it only in memory.
> 
> I m thinking of giving the password each time Tomcat is started.
> How do you force tomcat to ask a password during startup?
Doesn't do this out of the box. You need to write some custom code 
either in your app or to modify Tomcat directly.

> How do you avoid memory swapping?
With great difficulty.

> And is there any risk that the password is
> removed from
> memory even that Tomcat is running? How to avoid this?
Yes but a very low one. Avoiding it is really difficult.

> Do you have better solutions?
You seem to be trying to mitigate against the risk of an unauthorised 
user gaining access to the Tomcat box and reading the password of the 
disk. If an attacker has access to the box you have much bigger 
problems. They could, for example,
- replace your webapp with one that emailed them every piece of data 
that your webapp encrypts
- trash your box
- in fact, pretty much whatever they like

Fundamentally you seem to have a very narrow view of your threats and 
are missing some which are much bigger and much easier for an attacker 
to implement. BTW, if your app requires 24x7 availability you will 
need at least 5 people who know the pass-phrase.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org