[Owasp-appsensor-project] Custom AppSensorSecurityConfiguration

Kevin W. Wall kevin.w.wall at gmail.com
Wed Aug 24 10:11:13 EDT 2011


On Wed, Aug 24, 2011 at 9:31 AM, John Melton <jtmelton at gmail.com> wrote:
> Theo,
> That's an interesting solution. If you feel like you might want to exert the
> energy to contribute the code, I think it would probably fit better into
> ESAPI, so would suggest you email the esapi dev list with the paragraph
> description below, and get feedback from those guys. Then you can push the
> code into ESAPI as an optional key management solution. There are many
> possible solutions the key management issue, and the implementation of those
> are often difficult to get right b/c of certain nuances.
> Thanks,
> John
>
> On Wed, Aug 24, 2011 at 9:24 AM, Theo van Niekerk <theovn at owasp.org> wrote:
>>
>> Hi John
>>
>> Thanks for your reply - I'll try and file a bug/issue.
>>
>> I store the Master-key (password protected) in a Key-store (also password
>> protected).
>> My app has an obscure webpage that asks for these 2 passwords to load the
>> Master-key in memory where it is kept
>> The app won't run - returns 503 on most dynamic pages - unless the key is
>> loaded.
>> Downside is on a server restart, an operator needs to enter the passwords.
>> Upside is that one can make the statement that 2 operators each with their
>> own password are required to start the app.
>> I think that if you are not involved/aware of a server/app restart then
>> you are doing something wrong.
>>
>> I don't mind sharing/contributing the code - it works for me, but it's not
>> a work of art.

This is something similar to the work I had tentatively planned for ESAPI 2.1.
I was planning on doing it when I fix the broken public key crypto. Currently,
in 2.0.x, the key pair is generated on the fly but never persisted, so as soon
as the JVM process dies, the keys disappear as well. Next start-up, you get
a different key pair, which makes the public key crypto in ESAPI 2.0 mostly
useless.  I figured that in 2.1, I'd store / retrieve key pairs in a
Java KeyStore
and password protect the keystore as you have done. I was planning on
offering other alternatives besides having an operations team manually
enter a password, since generally most shops wish to take a lights-out
approach, but there are other possibilities as well. I've already done
things like this in a general key server that my AppSec team wrote
at my day job, so I don't think it would be too hard. I probably could of
had most of it done, but the crypto sections of code more or less had a
code freeze for about 5 months while the NSA was reviewing it.

However, ESAPI would definitely welcome you to contribute your
code to the 'contrib' section. You may want to tidy it up or ask
someone to review it and it's documentation before you contribute
it, but in general, I think it would serve as a great stopgap until
2.1 is available with a more integrated solution.

Chris: What does Theo need to do to be able to commit to the ESAPI 'contrib'
          section?

Thanks,
-kevin
-- 
Blog: http://off-the-wall-security.blogspot.com/
"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


More information about the Owasp-appsensor-project mailing list