Comment by jpalomaki | Hacker News Reader

Comment by jpalomaki | Hacker News Reader

Parent Full thread

I think most should be actually checking the "OWASP Application Security Verification Standard Project" [1] instead of just the Top 10 list.

The application security verification standard has quite clear requirements that you can just feed into your software development process. The requirements are split to three different levels, L1, L2 and L3. L1 requirements are more or less straightforward, standard application development stuff. L2 and L3 go more into processes. The idea is also that the L1 requirements can be verified by external penetration testing, without access to source code.

I would say the L1 requirements are something everybody involved in creating web apps professionally should check. Maybe some the requirements don't make sense for your particular application, but for those cases it is a good exercise to write down why not.

[1] https://www.owasp.org/index.php/Category:OWASP_Application_S... (the document can be downloaded from the links on the right side)

ASVS is a good idea, but it has forever lost its credibility for me after the following recommendation appeared in one of its published documents (2.13 I believe, level 1 ASVSv3):

>Verify that account passwords make use of a sufficient strength encryption routine and that it withstands brute force attack against the encryption routine

I think this has been fixed, but I don't understand why encryption (which implies reversibility) was ever advocated over a proper password hashing method such as BCrypt or PBKDF2. And no, using terms like "one way encryption" would not be any better - it shows a general lack of understanding.

Errors and mistakes are somewhat inevitable in larger projects, and ASVS covers a lot of ground.

One of the benefits is that it's open source, so you're free to contribute to improve it.

There is a general lack of understanding. OWASP is a shambolic volunteer project and its outputs are uneven at best. I would be particularly wary of OWASP when it comes to specialist topics, and cryptography is a great example of that.

That’s a bit disheartening. OWASP isn’t perfect, but it’s definitely a step up the ladder for the kind of teams that aren’t using HTTPS, and storing passwords in plain text. Having an official set of fairly specific instructions helps move the discussion away from the subjective “single quotes are more secure than double quotes” type discussions.

If you're at that level of security immaturity, pretty much any mainstream resource is going to be helpful and will work out for you; OWASP is fine.

What's the next step up?

As of now? ASVS v4: https://www.owasp.org/images/d/d4/OWASP_Application_Security...

At least for software security, this is probably the best single reference you'll find to get from level 1 to 2 (assuming zero is your origin), regardless of ptacek's largely unfalsifiable objections. Absent from these comments are any other software-security-specific recommendations -- though if you're looking for something more holistic rather than just being siloed to software security specifically, you may consider following NIST CSF to start and then exploring mitigating common patterns exposed in the ATT&CK framework.

If you're looking more for guidance on what other companies are doing for securing development pipelines, probably BSIMM. Bear in mind it's the product of a consulting firm, and all it does is tell you the things others do, not necessarily what's actually effective (descriptive v. prescriptive). The result is that it may be tuned to steer consulting traffic their way. Full disclosure: I've consumed that consulting service at two firms thus far.

Look at ASVS v4 in the context of this subthread about password storage. ASVS provides a list of approved password hashes (or rather, borrows one from an external source), then makes a recommendation about salt size (?!), and concludes by saying applications should run the password hash twice, once with a salt that is a secret key, which (1) is a silly, broken recommendation and (2) isn't a norm in application security at all, but rather is fan service for some random contributor who believes this is a good idea. Why would you trust ASVS?

That entire section was lifted wholesale (32 bits and all) from NIST 800-63b 5.1.1.2 and as a result is specific to contexts where these requirements provide added security guarantees when processing constraints are expected (re: 32 bit salt minimums as well as secret salts / "pepper" in discrete HSMs). This probably isn't right for a number of organizations, but the standards are researched with rehabilitating the most security-impaired organizations/agencies in mind — using prescriptions derived from data. While the ASVS targets a slightly different audience, it's striving to prescribe easily accessible instructions rather than the state of the art (though the two make a pretty tight Venn diagram).

I understand and largely agree with your technical gripes though I regret to say I'm not really convinced by your position. That said, I agree with an unstated corollary to your point: 2.4.5's listing as a L2 control is not appropriate (L3 would be better where this requirement even makes sense), and this specific recommendation should be traded for an alternate prescription in favor of credential-specific hard-i.e.-long salts, because most environments outside the ones NIST cares about actually have the capability to follow the state of the art rather than hack together a solution to fit processing constraints.

---

To your point about mature security programs: you're entirely right. Without those resource constraints, I'd build a program modeled off of real world threats and attack surface as well as actual usage and abuse. No need for a general prescription when I can diagnose my specific shortcomings. You and I are in agreement there. (Talks like "using vulnerability trend analysis to guide holistic security uplift" by salesforce come to mind)

---

Responding from mobile. Please pardon any typing defects. And if you're at Security@ today, I'm up to chat more over foods.

I've been trying to make sense of 2.4.5 for a while and have come up short. So thank you for that insight.

It is frustrating working in an environment where the ASVS is held up as infallible...

An unfortunate part is that 2.1.2, 2.1.3, 2.1.4, 2.1.7 and 2.1.11 are all issues I've fought of favor of previously (many.. many times), and one of my best assets in that fight an "appeal to authority" by positioning documents like this.

So, as a full-time practitioner in the space with multiple decades of experience, one among many that read and comment on HN, I'm just going to say that ASVS has essentially no currency whatsoever in serious application security practices (like, the practices run by clueful tech companies with large security teams, or NCC Group and any of its constituent companies, or, as far as I know, other large-ish consulting practices like Bishop Fox or Gotham).

I appreciate that the documents are helpful as appeals to authority to win dumb arguments and am not saying you shouldn't do that! But it is weird for me to hear that people outside my field take ASVS especially seriously.

That's a big question, and I don't want to crud the thread up. My point was just, if you're at the point where you're arguing about single quotes versus double quotes, OWASP is just fine as a starting point.

OWASP may be a shambolic volunteer project, but it's interesting that, in many areas, it's still the best thing available for the last 18 years...

Is that interesting? Are other aspects of computing more mature? I look at the kind of stuff Kyle Kingsbury finds with Jepsen and wonder.

Well I find it interesting :) A huge quantity of value flows through web applications, they're used by pretty much every business sector in the world for a wide range of purposes.

Security vulnerabilities in Web applications have been a major cause of big losses at a large number of these companies.

Despite that, the most authoritative, best funded, Web application security group is OWASP. A group with a full-time staff of < 10, and an annual budget of well under $10M.

It's interesting to me anyway, that the wider IT industry doesn't see value in trying to establish security practices and tooling which could be used to reduce some of these losses. Even if they don't like OWASP itself for any reason, that they don't look to establish something else to achieve the same goal.

Anybody have any other sites or books/resources that they would recommend?

> OWASP is a shambolic volunteer project and its outputs are uneven at best.

Have you considered contributing recently?

No.

Did not know this existed. Very cool

Reply on news.ycombinator.com