[Esapi-user] FW: [Esapi-dev] Call for review of crypto code

Boberski, Michael [USA] boberski_michael at bah.com
Fri Apr 30 15:55:49 EDT 2010

Jim, one email more from this morning, with Kevin's response to my proposal, below.


Mike B.

-----Original Message-----
From: Kevin W. Wall [mailto:kevin.w.wall at gmail.com] 
Sent: Friday, April 30, 2010 12:14 PM
To: Boberski, Michael [USA]
Subject: Re: [Esapi-dev] [Esapi-user] Call for review of crypto code

Boberski, Michael [USA] wrote:
>>> It's our use of algorithms and key management that we should solicit reviews of.
>> I completely agree with this and have been saying this all along.
> Kevin, an idea. Let's add some crypto sections here: http://code.google.com/p/owasp-esapi-java/wiki/esapi4java_v2_Sample_usage to specifically focus people on the above "top down" approach.
> If we can come up with some domain-specific requirements/use cases for using ESAPI crypto, then we can give someone a link and say for this business purpose is it "right" to you, and they can drill down to the degree they wish, but starting from the top down.
> For example, maybe let's add a PCI section:
>     * Sample usage
>           o Using ESAPI to meet ASVS requirements
>                 + ...
>           o Using ESAPI to meet PCI requirements <-- I CAN ADD THIS
>                 + ...
>                 + Requirement 3: Protect stored cardholder data <-- YOU/WE CAN WRITE THIS
>                 + ...
>           o Using ESAPI's WAF
>                 + ...
> E.g., how would you do this using ESAPI: "For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not
> needed, and not sending PAN in unencrypted e-mails. "
> Is it a best practice to encrypt not just cardholder data but also encrypt truncated cardholder data, or subsets of data in either case, and provide some direction as to which data/datum to encrypt and use code snippets with variable names that imply ESAPI's being used for that purpose. Would you use ESAPI to encrypt emails (I know the answer, but you'd provide guidance in the sample usage that that's not what ESAPI's intended for), another example of how to direct and scope the review.
> Note, doesn't have to be PCI, can be any other source that you want. For example, a scenario that compels the use of MACs.
> Way forward?

Sounds good to me. I also think it's important because (for example) I think
your average developer doesn't know when data integrity is important. I've
seen many that just put an encrypted CC# into an XML SOAP request and think
that's safe, and then fire off a web service call over an insecure comm
channel. They don't think that someone can *replace* that encrypted CC# or
other info in that web service call.


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

More information about the Esapi-user mailing list