[WEB SECURITY] Encrypting Client Data

Jim Manico jim at manico.net
Sun Jun 12 00:06:44 EDT 2011

Since this is for a high-assurance/low-risk app....

The only slight risk with this mechanism (if it is a Java system)  is
how little you can depend on garbage collection. The other problem
involves strings getting stored in the JVM string pool for a
non-deterministic amount of time. You may want to do your crypto
operations in a separate process that kills the JVM right after each
individual crypto action.

- Jim 
>> The database information is now secure and you only
>> need to protect the encryption keys at the application
>> layer - which is a completely different conversation...
> Precisely, their proposed model does exactly what you said, and their
> method for storing the keys is, well, not to store them; just pass the
> key off to the end-user and have them keep it stored on their end and
> provide them to the application when needed.  The people who want the
> application built are very risk-averse and don't trust the keys to be
> stored anywhere that the server/application/staff has direct access to
> them.  Personally, I'd prefer a more standard key management system
> but the thought of us even having both the encrypted data and the keys
> makes the business very, very nervous.  Eventually the data and keys
> have to come together, so there is always some risk, they just want it
> to be as reduced as possible and still get the application built.
> -Justin
> _______________________________________________
> The Web Security Mailing List
> WebSecurity RSS Feed
> http://www.webappsec.org/rss/websecurity.rss
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> WASC on Twitter
> http://twitter.com/wascupdates
> websecurity at lists.webappsec.org
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

More information about the websecurity mailing list