I will only use vetted and published algorithms
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. The problem isn't algorithms. The problem is constructions, particularly at the joints.
You should change this to "I will only use vetted high-level cryptographic libraries", with the descriptive text explaining that a "high-level cryptographic library" is one that handles key generation and makes all the decisions about block cipher modes and MACs and verification and order-of-operations for you.
So with that having been said:
I will not store sensitive data in plain text
Encouraging people to encrypt data while giving them bad advice about how to accomplish that is a recipe for disaster.
Next:
I will use parameterized queries when executing SQL
Specifically, you write: "Parameterized queries are a better way of solving the problem, because it doesn't require any escaping". This is wrong. Most database protocols will allow you to bind data to a query, but not keywords, or even limits and offsets. A whole generation of programmers has been convinced that using parameterized queries shields them from SQL Injection, while writing pagination code or sortable tables that are trivially injectable.
Finally:
I will understand the OWASP top 10
I can't knock you for asking people to know what the OWASP top 10 is, but contra the words in your pledge, "OWASP" (whatever that is in reality) does not "track" the "top 10" vulnerabilities in any methodical way. It's basically just a bunch of people getting together and making a case for what they think the most important vulnerabilities are. 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.
> 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...
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?
No.
Someone who knew their way around cryptography algorithms could do that. I can't. This is good advice for someone who isn't a security expert. (Edit: With my level of crypto knowledge, I don't even know how to evaluate whether your claim bears any relationship to reality.)
(Yes. I would like to remedy that. I'm working on it, slowly.)
Your AES code, I am implying, would be so bad that you'd be better off not having used it at all.
By this logic, Gmail would need to encrypt the contents of every email and every attachment, then encyrpt the full-text indexes of those emails and attachments. Obviously my contacts should be encrypted too. Then they'd need to encrypt the names of all labels/tags, which can contain sensitive information. Then they'd need to encrypt their logs, since when I visit the service and from where is actually sometimes sensitive info.
This is basically endless. It's impossible to accurately asses the bounds of what an arbitrary user will consider sensitive. The core is reasonably easy -- passwords, CC numbers -- but there can be hugely sensitive data at the edges.
My favorite example of this at the moment is 1Password. 1Password does a very thorough job of encrypting their passwords file. You can go read a whole blog post and white paper they wrote on their keychain format. But it turns out (as I and others have raised in their forums) there is a cache they create in the clear in the filesystem where the cache files are named after the websites where you have an account and have recently visited.
Now MANY people will not consider this sensitive data. But some people will. The passwords are not leaking, but the names of sites where I have accounts IS leaking. No problem, unless you have an account at donkey-fetish-dot-xxx your partner doesn't know about or whatever. The guys who designed 1Password clearly didn't think this issue would come up because, to their credit, they probably don't spend a lot of time on sites like private-pirated-movie-trove-dot-info. Or they don't have spouses/bosses who know where to look for these cache files.
Anyway, this is a long way of saying that you'll go crazy trying to encrypt all sensitive info. I think the 1Password case is clear cut but, judging by the response from their support, they did not. You might think a users' bookmark tag is not sensitive info, but if it's named 'job-hunt' or 'divorce-lawyers' it probably is. In the end, everything is sensitive info to someone.
"Encrypt all data" is something that sounds good in a message board thread, but really doesn't do much to shield you from the fact that to be secure, you just have to flush all the bugs out of your application.
An important addendum to "I will use existing libraries where possible" --
you should also pledge to share those implementations freely. This will allow
your implementations to enjoy the same scrutiny that the implementations of
others have (cf. "I will only use vetted and published algorithms") and
enrich the development community.
I won't make use of programming languages that make it easy to do security exploits