[Esapi-dev] Towards ESAPI 3

Kevin W. Wall kevin.w.wall at gmail.com
Tue Dec 10 23:06:59 UTC 2013


As you are aware, the security configuration in
ESAPI 2.x and earlier is a mess. Because the crypto
has need to change be able to support alternate
encryption algorithms simultaneously (e.g., AES
*and* DESede for example), I am rewriting the
JavaEncryptor so that it is no longer a singleton.
This will allow me to support that as well as
being able to fully support NIST KDF 'context'

which will help remove secret key / IV reuse
(as unlikely as that may be) with any stream
cipher mode that might be used.

Anyhow, for now, that is in ESAPI 2.1.x, I was
NOT planning on tweaking the Encryptor interface.
I intend to completely rewrite that for 3.0, so
this means that I intend to add some new methods
and CTORs directly in JavaEncryptor (ugh! why didn't
we pick DefaultEncryptor to follow the pattern of
most other ESAPI reference implementations, but
I digress).

Given that they are at least a 1/2 dozen or
so crypto-relatedd properties that a developer
may wish to tweak from one instance of JavaEncryptor
to another (e.g., encryption algorithm, signature
algorithm, hash iterations, etc.), I think that it
is obvious that I do not want to provide setters
for each of these possibilities. Likewise, I
think having a new CTOR where a developer has
to specify all of these properties separately is
likely to be a problem as well.

So my proposal is to do provide a new CTOR something
like this:
    *   Construct a new {@code JavaEncryptor} instance with the specified
    *   properties. The properties from {@code ESAPI.properties}
    *   are first applied and the specified properties are then loaded via
    *   the {@code Properties(Properties)} constructor to override the
    *   defaults.
    *   @param  props   New properties that override the default
    *                   crypto-related properties. Note that these property
    *                   values only apply to this particular instance. If an
    *                   unknown property or a non-crypto related property
    *                   is given, then those properties are simply silently
    *                   ignored and the relevant default property is used
    *                   instead.
    public JavaEncryptor(Properties props)

[Note: Alternately, there could be a new
method. For now, let's go with the CTOR approach.]

Now, here is the rub. Because we didn't specify a separate class or
interface to specify ESAPI property names (e.g.,
if we allow this, so we will developers hard-coding these property names
their source code in order to use this new functionality. That's something
I think that we should avoid as it makes the migration path to ESAPI 3.0
that much more difficult.

So, it would be nice if we had these property names hard-coded as
constant strings somewhere that they could use them.

But wait...we already do...sort of. They are all there the reference
implementation, org.owasp.esapi.reference.DefaultSecurityConfiguration.

But wait...that's a reference implementation class, so even though these
properties are public, we probably do NOT want to encourage to do things

  tdesEncryptor = new JavaEncryptor(
      new Properties().setProperty(
          "DESede/CBC/PKC5Padding") );

Surely that is even uglier than hard-coding it as:

  tdesEncryptor = new JavaEncryptor(
      new Properties().setProperty("Encryptor.CipherTransformation",
                                   "DESede/CBC/PKCS5Padding") );

One problem as I see it is that the ESAPI property names are defined in
org.owasp.esapi.reference.DefaultSecurityConfiguration. (They are also
in org.owasp.esapi.DefaultSecurityConfigurationTest under src/test/java
as well, so we've managed to screw ourselves by putting them in two places.)

Anyhow, the obvious, easy thing to do would seem to pick some new class and
move all these property names to there as public static final Strings. E.g.,
something like:
Or if we every intend to bounce every support other ESAPI configuration
such as loading from an XML file, instead of simple Java property names, we
want XPaths so perhaps either we have multiple property files, such as:

(or alternately, use nested classes, which IMO just makes things messier).

Anyway, I just wanted to get your idea for an approach. The kludge that we
have with (re)setting the SecurityConfiguration from the ESAPI service class
is not suitable for production and neither is the current (deprecated) hack
that I have now that simply is intended to allow me to test multiple

But thought I'd ask you and the larger ESAPI developer community (assuming
are more than the two of us still subscribed to this mailing list ;-) to get
your feedback.  I don't really think this will impact the crypto interfaces
for ESAPI 3.0, but I do think it could have a major impact on how difficult
we make that part of the migration path from ESAPI 2.x to 3.0.  And since I
am gutting JavaEncryptor for other reasons (to address CVE-2013-5960;
was fixed, but the other is a design issue), now seems like the right time
to do this.

Blog: http://off-the-wall-security.blogspot.com/
NSA: All your crypto bit are belong to us.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/esapi-dev/attachments/20131210/db16982e/attachment.html>

More information about the Esapi-dev mailing list