On Tue, Feb 24, 2009 at 03:06:21PM -0500, Perry E. Metzger wrote: > If you expect to be presenting things at that level of detail to > developers, you're going to lose.
Agreed on this end. However, these are web security people, not mere web developers. They are very sharp on complicated issues like web security, and just today one of them was joking about how one web developer thought that hidden fields in forms are immutable. > There is no chance that they'll > absorb the details, and they'll get entirely the wrong message, which > is that they should be making decisions on such things instead of just > using prepackaged protocols. Hmm, interesting thought. I was hoping to present the multiple failures (by smart people) as a way to convince them of the need to use existing algorithms rather than try to design their own. This actually touches on something I've noticed. With a locally-executing application, the operating system provides abstractions like user IDs and file permissions that an application developer gets "for free", and by and large they are making effective use of them. However, in the web application or web services world, nearly everyone* is doing things like user account management from scratch, and they're making the same sort of mistakes over and over again. [*] There are possible exceptions in web application frameworks like Zope. Some of these systems may already provide security features and abstractions that can be used by web developers. > The single most important lesson in cryptography is that cryptography > and cryptographic protocols are insanely hard to get right. Strong agreement. > The > average PHP hacker is not in a position to spend enough time to learn > the field well enough -- he's busy getting his application > working. Much better to avoid the entire issue. I'm not so sure; it seems that, for better or worse, web developers are doing these things, and they're doing them wrong. Hopefully this presentation will deliver two messages; one, that cryptography and cryptographic protocols are insanely hard to get right, and two, that they should use some relatively standard mechanisms for implementing their crypto, like AES256-CBC (for confidentiality) and SHA-2-HMAC (for integrity protection). But I suppose it could backfire, if people came away with the notion that _now_ they are educated enough on crypto to make informed decisions about new combinations. Maybe I should make a point of telling them that this is not the case. -- Obama Nation | It's not like I'm encrypting... it's more like I've developed a massive entropy deficiency | http://www.subsubpacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com