5 ms·

The Secure Programmer's Pledge

59 points by ircmaxell 14y ago

tptacek 14y ago
Problems: 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.
- ircmaxell 14y ago
  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.
- JoachimSchipper 14y ago
  (Psst, your reply to maxgrep is [dead].)
  - tptacek 14y ago
    Weird. Tried to recover it, gave up. Other readers: you're not missing much. :)
- ori_b 14y ago
  > 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. 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.)
  - tptacek 14y ago
    Are you sure you're right about that? Because I think you're wrong. I think you could spend 15 minutes on Wikipedia, write your own block cipher core, and if you used Keyczar as the protocol implementation, you'd be better off than if you had used AES directly. Your AES code, I am implying, would be so bad that you'd be better off not having used it at all.
    - deleted 14y ago
      [deleted]
    - deleted 14y ago
      [deleted]
    - ircmaxell 14y ago
      That's fair. However I'd argue that someone implementing their own algorithm would not use a library like keyczar. They would just write their own. So while it's possible to write your own and be secure, IMHO it'd be better to stick to vetted algorithms and libraries... I think it's just that - all other things being equal - the public algorithm is more likely to be more secure...
pjmlp 14y ago
One entry missing: I won't make use of programming languages that make it easy to do security exploits
mapgrep 14y ago
"I will not store sensitive data in plain text" 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.
- tptacek 14y ago
  Particularly with web apps, this "encrypt all the sensitive data" stuff is usually masturbatory. If it's data your application needs to function, the server needs ready access either to the key, or at least to some online oracle that provides access to the data. So you end up with these silly systems that encrypt data under AES keys stored, at best, on the filesystem. "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.
Cyranix 14y ago
Left this as a comment on the blog posting, but felt it might be worth reiterating here: 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. Without this bit -- especially if your target audience is average developers -- you're inadvertently condoning ignorance due to lack of peer review.
avstraliitski 14y ago
I am a (web programmer with some experience now viewing myself as a) secure programmer: 1. I will not store sensitive data in plain text, I will protect it in a suitable manner. (EXCEPT when I realize that security, scalability, performance and other requirements are often such that plain text from an application level may be secured adequately through other system components. Thus, citing 'plain text' as something to avoid is an inherently flawed approach, as it breaks the modular assumption that good code (Unix) is built upon. Do one thing and do it well.) 2. I will always protect my users' data as if it was my own. (Good luck with that when you have hundreds of millions of them and competing availability/scalability requirements. Security is about carefully managing risk against goals and available resources, not idealism/dogmatism.) 3. I will only use vetted and published algorithms, I will not invent my own. (A recommended course of action for aspects of cryptography; elsewhere - good luck programming!) 4. I will use existing libraries where possible, and only write my own implementation where no suitable alternative exists. (While sometimes of value, dogmatically using this approach is more of a pledge to be a mediocre programmer.) 5. I will always use parameterized queries when executing SQL, I will not trust escaping. (This is just wrong, as addressed in other comments) 6. I will take vulnerabilities seriously, and not just ignore them when found. (Yes) 7. I will understand the OWASP Top 10 vulnerabilities, and will always protect my applications from them. (Yes but this hardly needs saying) 8. I will not assume that I know better, but instead will try to constantly learn. (Yes, but this could be "don't be an asshole" pledge, also) 9. I will not trust the security of systems that I have not personally examined. (Yes, but then this goes back to Unix philosophy - do one thing and do it well. Also, one should admit one's own limitations and not pretend that by examining something it's 100% bug free and secure. Many a smart programmer has created or missed bugs in insecure code on a bad day.) I will always try to educate others. (A worthy but tiresome goal, consider these probably-snarky-sounding but actually well meaning comments my own contribution)

59 points by ircmaxell 14y ago

Problems: 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.

ircmaxell 14y ago
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.
JoachimSchipper 14y ago
(Psst, your reply to maxgrep is [dead].)
- tptacek 14y ago
  Weird. Tried to recover it, gave up. Other readers: you're not missing much. :)
ori_b 14y ago
> 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. 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.)
- tptacek 14y ago
  Are you sure you're right about that? Because I think you're wrong. I think you could spend 15 minutes on Wikipedia, write your own block cipher core, and if you used Keyczar as the protocol implementation, you'd be better off than if you had used AES directly. Your AES code, I am implying, would be so bad that you'd be better off not having used it at all.
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]
  - ircmaxell 14y ago
    That's fair. However I'd argue that someone implementing their own algorithm would not use a library like keyczar. They would just write their own. So while it's possible to write your own and be secure, IMHO it'd be better to stick to vetted algorithms and libraries... I think it's just that - all other things being equal - the public algorithm is more likely to be more secure...

pjmlp 14y ago

One entry missing: I won't make use of programming languages that make it easy to do security exploits

mapgrep 14y ago

"I will not store sensitive data in plain text" 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.

tptacek 14y ago
Particularly with web apps, this "encrypt all the sensitive data" stuff is usually masturbatory. If it's data your application needs to function, the server needs ready access either to the key, or at least to some online oracle that provides access to the data. So you end up with these silly systems that encrypt data under AES keys stored, at best, on the filesystem. "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.

Cyranix 14y ago

Left this as a comment on the blog posting, but felt it might be worth reiterating here: 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. Without this bit -- especially if your target audience is average developers -- you're inadvertently condoning ignorance due to lack of peer review.

avstraliitski 14y ago

I am a (web programmer with some experience now viewing myself as a) secure programmer: 1. I will not store sensitive data in plain text, I will protect it in a suitable manner. (EXCEPT when I realize that security, scalability, performance and other requirements are often such that plain text from an application level may be secured adequately through other system components. Thus, citing 'plain text' as something to avoid is an inherently flawed approach, as it breaks the modular assumption that good code (Unix) is built upon. Do one thing and do it well.) 2. I will always protect my users' data as if it was my own. (Good luck with that when you have hundreds of millions of them and competing availability/scalability requirements. Security is about carefully managing risk against goals and available resources, not idealism/dogmatism.) 3. I will only use vetted and published algorithms, I will not invent my own. (A recommended course of action for aspects of cryptography; elsewhere - good luck programming!) 4. I will use existing libraries where possible, and only write my own implementation where no suitable alternative exists. (While sometimes of value, dogmatically using this approach is more of a pledge to be a mediocre programmer.) 5. I will always use parameterized queries when executing SQL, I will not trust escaping. (This is just wrong, as addressed in other comments) 6. I will take vulnerabilities seriously, and not just ignore them when found. (Yes) 7. I will understand the OWASP Top 10 vulnerabilities, and will always protect my applications from them. (Yes but this hardly needs saying) 8. I will not assume that I know better, but instead will try to constantly learn. (Yes, but this could be "don't be an asshole" pledge, also) 9. I will not trust the security of systems that I have not personally examined. (Yes, but then this goes back to Unix philosophy - do one thing and do it well. Also, one should admit one's own limitations and not pretend that by examining something it's 100% bug free and secure. Many a smart programmer has created or missed bugs in insecure code on a bad day.) I will always try to educate others. (A worthy but tiresome goal, consider these probably-snarky-sounding but actually well meaning comments my own contribution)