The OWASP Top 10 is a somewhat useful benchmark and an easy way of communicating the general concept of web application security to people; it's especially useful when an assessment might involve both web security and other stuff, and you want to be clear that you're just poking at the web stuff.
Apart from that: OWASP is not a very reliable resource. The project has given some genuinely bad advice over the years. In particular: don't rely on any advice they give about cryptography.
The only crypto advice I see in this guide is on page 37.
https://www.owasp.org/images/6/67/OWASPApplicationSecurityVe...
That entire section is incorrect?
You should be using ECDH, EdDSA, and (authenticated) stream ciphers. Padding shouldn't even be a thing.
> Verify that cryptographic algorithms used by the application have been validated against FIPS 140-2 or an equivalent standard.
FIPS 140-2 is bullshit. Try being FIPS 140-2 compliant on a Debian Squeeze server running Apache 2.2 (i.e. TLS 1.0 is the highest you can go) while also being PCI compliant. Spoiler: The only way to be both PCI and FIPS 140-2 compliant is to use TLS 1.2 with AES-GCM and SHA2.
Standards rarely make good cryptographic choices. Winners of cryptography competitions, on the other hand, do.
> Verify that cryptographic modules operate in their approved mode according to their published security policies.
This is so vague it's not actionable.
This is like Malcolm Gladwell's Igon Values thing, except it's in a prescriptive technical document.
Nope nope nope. If you're going to make security recommendations, you have to know what you're talking about .
EDIT: This is absolutely the book I was looking for the other day and didn't know existed, most of this stuff I'm familiar with but this looks like an excellent refresher.
Plus, a brain injury in an accident cost me most of my memory. I operate on fragments now while trying to reconnect stuff. I probably knew about the guide and forgot. Or I didn't but used something else. Usually remember a lot of INFOSEC stuff but this one is total blank. So, such resources are good for getting stuff back in my head.
Here's last list I put up when my memory was working better than ATM that detailed what kinds approaches I recommended or used (often in combination):
https://www.schneier.com/blog/archives/2014/04/the_security_...
I know I used a SPECTRE clone in the past for at least one legacy app. Did high-assurance HTTP to prevent defacing. Did an application server on microkernel similar to Barracuda's nice architecture to keep TCB minimal. Outside SPECTRE, it's what we all did in high-assurance though: certain things everyone seems to build. The rest and all details are a blank. Sorry...
Barracuda lightweight approach https://realtimelogic.com/products/lua-server-pages/
Nonetheless, I've been fighting for civil liberties and privacy a long time. Plus trying to do bulletproof systems. Even with gaps & lacking specialist skill, I'm closer now than ever mapping & semi-synthesizing systems from high-level specs all the way to transistors with reliability, security, & recovery via dozens of techniques. Dedicated endpoint mostly solved, client server too, Web is if you cheat (I did proxies), P2P still open-ended, and much more to do in decentralized. Plus my activity here and elsewhere of evangelizing strong methods & making sure old wisdom doesn't get lost. Got motivation & keep active so remaining synapses get reinforcement.
So, a little brain injury and Memento-style moments ain't enough to totally knock me out of the game. Just gotta get it back piece by piece & be more mentally efficient than before. Wirth-style ultra-simplification & Dijkstra abstraction pays off there. Anyway, NSA gonna shit their pants when I go commercial again. Short-term rather than long-term goal hopefully. ;)
I hadn't read that book until the middle of last year, and I didn't learn anything new from it because I taught myself all those concepts over the years. It was, nonetheless, a good read. So, I wouldn't make that claim to begin with.
I just thought nickpsecurity had seen your reading list before is all. I see you two commenting on the same threads all the time.
This is the problem with crypto experts. You're all "find a crypto expert". But you just sit there on your thumbs and don't contribute in any way other than building libraries with such bad UX that lead to more "find a crypto expert" advice.
Well, I for one have been contributing, so there's that.
https://www.owasp.org/index.php?title=How_to_protect_sensiti...
I can clean up Stack Overflow, but not Google's search results.
I try where I can, and hope that makes an impact. (Aside: the people at the local OWASP chapter here in Orlando are competent and want to fix things. Not sure about everywhere else.)
Things may have gotten better in the last 2 years since I stopped paying attention (though: I doubt it), but my experience of it is that it's governed mostly by the kinds of consultants who parachute into projects to configure Fortify. Despite not having much software development experience, those kinds of consultants have very strong opinions about things like crypto.
The problem is very much not limited to crypto.
I think OWASP is mostly unsalvageable, and that the most productive thing to be done is to warn developers to take their advice with a grain of salt. There's useful stuff in there, but there's bad stuff too. That's fine if all you're purporting to build is a wiki, but it's less fine when your goal is to be the bible of appsec. They are simply not that.
Highlight:
Kerckhoff's principle applies to cryptography, not
application security.
- AbiusX, OWASP project leader for PHP Security
There are lots of things I could contribute to or fix. I pick the things I care about. The same is true for anyone that actually wants to improve things.
Lack of focus is the surest way to frustration and ineffectiveness.