[Esapi-user] [Esapi-dev] ESAPI Random Number Generation Broken
jim.manico at owasp.org
Tue Jul 1 03:04:24 UTC 2014
Thank you for helping and no pressure on time. If you want help or want to
pass these duties to me, I will endeavor to complain less and help more.
I appreciate your •volunteerism• here and am sorry for losing track of that.
On Jul 1, 2014, at 10:35 AM, Chris Schmidt <chrisisbeef at gmail.com> wrote:
We can push a zip a binary jar and a jar with just configs which is what I
had planned. I am slammed with work right now but plan to try and get this
out on weds night if there are no objections.
On Jun 29, 2014 11:33 PM, "Jim Manico" <jim.manico at owasp.org> wrote:
> Are doing the full zip release with all the config files, or just the jar
> release? Can we even push a zip to Maven central?
> Jim Manico
> (808) 652-3805
> On Jun 30, 2014, at 12:29 PM, Chris Schmidt <chrisisbeef at gmail.com> wrote:
> All - WRT to hosting the files, we will release 2.1.1 to Maven Central and
> point people to the download link there for downloading directly to keep it
> simple. I will do a release this week.
> On Sun, Jun 29, 2014 at 9:39 PM, Kevin W. Wall <kevin.w.wall at gmail.com>
>> On Sun, Jun 29, 2014 at 9:47 PM, Jim Manico <jim.manico at owasp.org> wrote:
>>> I am upset that the ESAPI team "blew off" this "poor CSRF token entropy"
>>> finding in 2011 when I was asked not to report Rook's finding even when his
>>> results were repeatable. It led to me leaving the project at the time. This
>>> is not just you, it was a group decision that I disagreed with. I did wait
>>> two years before disclosure and I'm glad to see it fixed.
>> Either I'm missing something, I'm more forgetful than I realize,
>> or I need some clarification. First of all, the first that I'm
>> seeing of this was some email that Jim forwarded from me that
>> came from David Rook back on Feb 21, 2012, not 2011. Did he
>> actually discover this earlier?
>> Second of all, I never recall anyone saying that we shouldn't
>> report this as a Google Issue. I do recall that several of us
>> wanted to better understand what was causing the unintuitive
>> Burp Sequencer results and there was a LOT of theories regarding
>> the explanation, but I personally don't recall anyone trying to
>> sweep in under the table. In fact as the years went by, I had
>> just assumed that their was a Google issue opened on it. I'm
>> surprised now to see that Jim opened issue 323 only back in
>> April of this year.
>> I personally had spent some time trying to get to the bottom
>> up it and come up with and explanation of the Burp Sequencer
>> results, but I gave up when I couldn't find a root cause. The
>> only thing that I did convince myself off was that it didn't
>> have anything at all to do with not reseeding SecureRandom.
>> (Note: Don't take that as a fact that I'm in support of the
>> use of DefaultRandomizer as a singleton or that we never
>> reseed it; I'm just stating that there was no way and no how
>> that we would ever seen any bias such as we observed with the
>> Burp Sequencer tests that David Rook ran in only 20k tokens.)
>> And truthfully, since the ESAPI crypto didn't use ESAPI Randomizer
>> and I wasn't convinced that it wasn't specifically a crypto
>> related problem, I lost interest and got involved with other
>> OWASP projects during GSoC and work on the Dev Guide.
>> So we all stand equally guilty to the OWASP community. Let's
>> get past that and come together and get it resolved.
>> First off is, Jeff has submitted a fix for this. Are we all in
>> agreement that foxes the root cause of this observed poor
>> results in the Burp Sequencer tests that David Rook first
>> made us aware of?
>> If we are all in agreement to that, how do we want to proceed?
>> Obviously a new version (2.1.1 or 18.104.22.168) would be the next in
>> line. Do we wish to include anything else in this new release?
>> Who will help out with it? Where should we host the new release
>> (besides Maven Central)? Should we have a CVE that we create for
>> Personally, I would like us to work together to do what's best
>> for the community of ESAPI users and most of all for the OWASP
>> reputation, and we are NOT clearing doing now.
>> If a few of you wish to vent your frustrations / feelings, I
>> think that that should be done on a personal level, and not
>> in public here. When I was being brought up, I was taught that
>> you praise in public and admonish in private and I still think
>> that's pretty good advice.
>> Maybe I'm sticking my neck in where it doesn't belong, but I'm
>> trying to be a peace maker here for the could of the OWASP
>> community and all this sniping is not helping. I know that,
>> you both know that, and everyone that is on these ESAPI
>> lists knows that as well.
>> So let's please act respectfully to each other...at least in
>> public so as not to further sully OWASP brand.
>> And if you want to flame me in person, that's fine. But if
>> you wish to do it in public, let's please keep it civil, polite,
>> and respectful and treat others like you would like to be treated.
>> That's all I have to say. Thanks for listening.
>> Esapi-user mailing list
>> Esapi-user at lists.owasp.org
> Chris Schmidt
> OWASP ESAPI Developer
> Check out OWASP ESAPI for Java
> Yet Another Developers Blog
> Bio and Resume
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Esapi-user