4 ms·
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 i
by blowski 7y ago
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.
- tptacek 7y agoIf 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.
- pas 7y agoWhat's the next step up?
- tptacek 7y agoThat'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.
- eganist 7y agoAs of now? ASVS v4: https://www.owasp.org/images/d/d4/OWASP_Application_Security_Verification_Standard_4.0-en.pdf 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.
- tptacek 7y agoLook 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?
- time0ut 7y agoI'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...
- technion 7y agoAn 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.
- tptacek 7y agoSo, 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.
- eganist 7y ago