[Owasp-webcert] OWASP Evaluation and Certification Criteria
andre at operations.net
Wed Aug 1 14:01:08 EDT 2007
On 8/1/07, Mark Curphey <mark at curphey.com> wrote:
> Todays update. I have not been able to make as much progress as I wanted
> yesterday and today. I know expect to finish the technology section
You're doing a great job so far! Keep up the momentum.
I wanted to try and nitpick on the username and password examples you
included before jumping into any of the others and get some feedback
on my feedback. I'm not sure if I'm coming across as annoying or
helpful, but I want to point out some potential flaws or areas for
> strong password should be 6 or 16 chars then well never get anywhere fast.
Passwords besides, I think UUID strings (i.e. your UM-00X?) should be
at least 16-bytes with average entropy e.g. the equivalent of `cat
/dev/urandom | tr -cd [:digits:] | fold -w 16 | head -1`. UUID's are
typically used for session ID's or user-based parameters.
PCI DSS states that passwords should be at least 7 characters in
length. I think that's fine for most systems using most modern-day
password storage routines. However, under Windows systems still
shipping with default LM hash storage technique (everything except
Vista), 7 characters should not be the minimum, as this cuts the
entropy of the hash in half. In all seriousness - they should be at
least 15 characters, preventing LM hash entirely (unless turned off by
some other means). My point here is that every system has its own
inherent issues - if you work around the issues to each particular
system - you gain the assurance needed.
For UM-002, you mention, "Email addresses should NOT be allowed as
usernames if email is one of the password reset options". I think at
higher levels of both application security (admin at email@example.com
type attacks), and reputation / user verification attacks
(dre at mailinator.com), most higher assured systems will not use email
address for almost any sort of trust relationship. Password reset is
ok, but we'll get to that at a much later time ;>
For UM-003, you say, "All user account management activity including
account maintenance, and password resets should take place using 256
bit SSL (with valid certificates)". I think that the 256-bit matters
less than the rest of it. By default, in most popular browsers that
I'm aware of, the default is AES-128 for encryption using certificates
that employ MD5 with a 1024-bit RSA public key. I think AES-128 is
fine for almost all applications, but that the RSA keys should be
2048-bit (the MD5 part is fine as long as used along with the RSA
key). This is actually a PKI issue, not an SSL configuration issue,
In UM-004, you suggest, "10 characters, at least 1 upper or lower case
and one numeric and one special character". What about repeating
characters? Maybe something that includes "same character not
repeated 3 times or more"? E.g. isn't aA-1111111 (10 chars) very
similar to aA-1 (4 chars)?
There's also common attack patterns for character combinations in
usernames and passwords that should probably be blacklisted, such as
> Also please remember this is a discussion document, proposing a better way
> to do web evaluation and certification that is out there today. This is not
> a build standard or a complete guide. Once I get this rev out of the door we
> can all sit around a table face to face at the next OWASP conference and
> work out the next steps to turn this into something real. There are great
> opportunities to hook this into the testing guide for issues and have them
> all dynamically update and keep current.
So, by this - you mean that all the little details of what provides
which level of assurance will get worked out at a later time? It does
seem like you are trying to populate the fields with some information
(although you're using copy/paste a lot - you'll probably need a
Copy-Paste Detector at some point!).
> Andres points about wanting to test throughout the lifecycle will be
> addressees by the Process part that will follow. In there we may have
> different techniques such as Threat Modeling. This way people can also just
> adopt the Technology part now and work towards the real deal later. This is
> a gentler learning curve and will likely see faster adoption as it will be
> less initial pain.
I think it's important to understand the overlap between penetration
testing for applications and QA testing. Threat modeling applies to
both ITO and Development equally well - interestingly enough.
Continuous testing and inspection mostly applies to just Dev.
Although there are SaaS vendors who would have you believe it also
applies to IT/Ops (and I'm not going to argue the point here, instead
I'll let them do it).
A lot of dev shops already have "some sort" of testing in place, just
like a lot of ITO shops have "some sort" of firewall already in place.
It's just a matter of using the right "capital" (your PPT) to
configure/verify/troubleshoot (CVT) the technology to a set of working
standards that allow for defined levels of assurance. In other words,
if you can get somebody to audit a firewall to certain controls - why
can't you get somebody to audit a QA functional test to certain
With basic building-blocks (you described the entire process as OOP at
the beginning of Part 1, which I thought was brilliant) in place, you
can generically assign assurance and areas for improvement to ITO or
Dev as if they are the same thing. It seems like this is what you are
trying to accomplish with this sort of criteria - and I'm all in favor
of it. The hard part that I see coming is relating the ideas behind
the Process to an organization that is very mature on the IMM scale,
but very immature on the CMM scale (or vice-versa).
More information about the Owasp-webcert