4 ms·

One point: this list/pledge is for average developers, not crypto experts... > This abets a hugely widespread misunderstanding about the security of crypto. Yo

One point: this list/pledge is for average developers, not crypto experts... > This abets a hugely widespread misunderstanding about the security of crypto. You could in fact invent your own block cipher core, and if you dropped it into Keyczar or cryptlib's high level library be more secure than people using AES-256 directly via OpenSSL. You could of course. But the average developer cannot. It takes quite a bit of knowledge about cryptography to be able to do this and have it be more secure than AES... And even if you have that knowledge the chance that a mistake was made is high enough that you shouldn't use it anyway (the algorithm isn't vetted). So I stand behind my point... > Encouraging people to encrypt data while giving them bad advice about how to accomplish that is a recipe for disaster. What bad advice? The only thing I said was hash it if you just need to verify, or encrypt if you need to reverse it. Additionally, would you rather have CC numbers stored in plain text? I'd rather have a botched encryption on them that's somewhat easy to break than have it in plain text... > Specifically, you write: "Parameterized queries are a better way of solving the problem, because it doesn't require any escaping". This is wrong. It's not wrong. Raw user input should never enter a query. Period. If you're going to paginate or sort or filter, you need to white-list filter on available fields and values. Escaping and adding it to the query is just a recipe for disaster... Obviously just using a parameterized query API isn't going to do it for you. But escaping, in any context, is an incorrect way of handling it... > If you know very little about web security, the OWASP Top 10 is a fine starting point, but your readers should know that's all it is. I'm not trying to suggest that they should only know the top 10, but that they should know it in its entirety...

hythloday 14y ago
I find it kinda sad that you have "I will not assume that I know better" and then your first reply is a point-by-point rebuttal of a paid expert's opinion. :)
tptacek 14y ago
Do you understand why I said a developer who wrote their own block cipher core and plugged it into Keyczar would be more secure than a developer who used AES directly? If you don't understand, why do you "stand behind your point"? Why don't you instead try asking questions? Similarly: you wrote none of that stuff about "whitelisting" (whatever it is you mean by that) in your "pledge". You just told developers, "use parameterized queries so you don't have to escape them". And now, when it's pointed out that that's not great advice, you find a way to argue with it?
- ircmaxell 14y ago
  Ok, I'll bite. Why would it be more secure? Would the following block cipher be more secure than AES? function encrypt(block, key) { return block XOR key; }
  - tptacek 14y ago
    That block cipher would not in practice be much worse than the cryptosystems developers end up with when they use OpenSSL, its bindings in Python or Ruby, or "javax.crypto" to get AES. AES in its default block cipher mode can usually be byte-at-a-time decrypted. AES in its "conservative" mode can almost always be byte-at-a-time decrypted when not augmented with another crypto building block that developers invariably forget. When developers don't forget that building block, they often manage to implement it in such a way that it too can by byte-at-a-time broken. AES in its most "modern" mode ends up being exactly as secure as naive XOR when developers use it without understanding its parameters. On the other hand, if you read the Wikipedia page on Feistel networks and wrote your own --- or if you just used reduced-round FEAL-4 --- but used Keyczar to actually deploy it against real data, all those mistakes I alluded to above would be avoided, and your attackers would have to do real cryptanalysis to attempt to break your application; nobody does that. Knowing this, you can now see why I'd take issue with the idea that your "Secure Progammer's Pledge" urges people to use "vetted algorithms" to protect data. AES is about as "vetted" as algorithms ever get, and its use in production code by generalist developers is almost always comically insecure. So: no, that one example turns out not to be more secure than AES, even in Keyczar. The problem is, by itself, it usually turns out not to be less secure either.
    - X-Istence 14y ago
      How would this change for example if instead of using just plain AES you use AES with a block cipher mode (CTR-BE/CBC/or others just no CBE)?
      - tptacek 14y ago
        If you read my comment carefully, you'll see I'm talking about mistakes people make when using "safe" block cipher modes. The default mode is ECB, by the way, not CBE.

hythloday 14y ago

I find it kinda sad that you have "I will not assume that I know better" and then your first reply is a point-by-point rebuttal of a paid expert's opinion. :)

tptacek 14y ago

Do you understand why I said a developer who wrote their own block cipher core and plugged it into Keyczar would be more secure than a developer who used AES directly? If you don't understand, why do you "stand behind your point"? Why don't you instead try asking questions? Similarly: you wrote none of that stuff about "whitelisting" (whatever it is you mean by that) in your "pledge". You just told developers, "use parameterized queries so you don't have to escape them". And now, when it's pointed out that that's not great advice, you find a way to argue with it?

ircmaxell 14y ago
Ok, I'll bite. Why would it be more secure? Would the following block cipher be more secure than AES? function encrypt(block, key) { return block XOR key; }
- tptacek 14y ago
  That block cipher would not in practice be much worse than the cryptosystems developers end up with when they use OpenSSL, its bindings in Python or Ruby, or "javax.crypto" to get AES. AES in its default block cipher mode can usually be byte-at-a-time decrypted. AES in its "conservative" mode can almost always be byte-at-a-time decrypted when not augmented with another crypto building block that developers invariably forget. When developers don't forget that building block, they often manage to implement it in such a way that it too can by byte-at-a-time broken. AES in its most "modern" mode ends up being exactly as secure as naive XOR when developers use it without understanding its parameters. On the other hand, if you read the Wikipedia page on Feistel networks and wrote your own --- or if you just used reduced-round FEAL-4 --- but used Keyczar to actually deploy it against real data, all those mistakes I alluded to above would be avoided, and your attackers would have to do real cryptanalysis to attempt to break your application; nobody does that. Knowing this, you can now see why I'd take issue with the idea that your "Secure Progammer's Pledge" urges people to use "vetted algorithms" to protect data. AES is about as "vetted" as algorithms ever get, and its use in production code by generalist developers is almost always comically insecure. So: no, that one example turns out not to be more secure than AES, even in Keyczar. The problem is, by itself, it usually turns out not to be less secure either.
  - X-Istence 14y ago
    How would this change for example if instead of using just plain AES you use AES with a block cipher mode (CTR-BE/CBC/or others just no CBE)?
    - tptacek 14y ago
      If you read my comment carefully, you'll see I'm talking about mistakes people make when using "safe" block cipher modes. The default mode is ECB, by the way, not CBE.