[Esapi-user] Thoughts on ESAPI's EncryptedProperties

Jeff Williams jeff.williams at aspectsecurity.com
Sat Apr 24 14:01:36 EDT 2010


I think it's an interesting idea.  Of course, they could simply encrypt
everything, but it definitely makes maintenance more difficult.

One solution to this that I've seen work in the field is to replace
plaintext properties with encrypted properties the first time the
application is run. This way, administrators can edit the properties and
set new values without having to use a special tool.

--Jeff


-----Original Message-----
From: esapi-user-bounces at lists.owasp.org
[mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Kevin W. Wall
Sent: Saturday, April 24, 2010 1:56 PM
To: ESAPI-Developers; ESAPI-Users
Subject: [Esapi-user] Thoughts on ESAPI's EncryptedProperties

As I started going through ESAPI's EncryptedProperties
interface and DefaultEncryptedProperties reference implementation,
I realized that one can not place encrypted properties and plaintext
properties in the same Java properties file.

I was wondering if that was a issue for anyone? At my day job,
my application security team provides a class that allows both
to be placed into the same jar.  The way that this works is
that any property name that contains '.sensitive' in the property
name is assumed to be encrypted so that when a getProperty() is
called with such a property name, it knows that to expect that such
a property is encrypted. All others are assumed to be unencrypted.

We provided this behavior at the request of several development teams
who do not want to keep around separate properties files for sensitive
information. (I imagine in part because all the changes to their
documentation
this would cause.)

Anyway, this sort of thing is pretty easy to write and I've thought
of providing it either as an example under "src/examples/java" or
to just provide it as a class within ESAPI proper.  (However, if I do
the latter, I will wait for the 2.1 branch has I don't wish to start
adding feeping creaturism like this into the 2.0 trunk.)

So what are your thoughts? Would something like that be useful?

And if you think "yes", do you think it should be placed into
an examples file now (in 2.0) or in a future version of core
ESAPI (2.1 or 3.0 or whatever the next branch will be)?

Thanks,
-kevin
--
Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME

_______________________________________________
Esapi-user mailing list
Esapi-user at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/esapi-user


More information about the Esapi-user mailing list