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
