In Why Isn't My Encryption.. Encrypting? we learned that your encryption is only as good as your understanding of the encryption code. And that the best encryption of all is no encryption, because you kept everything on the server, away from the prying eyes of the client.
I think abstraction here is a really poor choice of words for what you’re describing.
I also think you could’ve covered some of the pitfalls of using 3rd party libraries in your code, and how you need to abstract those out of the rest of your code for maintainability.
I dunno… maybe Coding Horror has jumped the shark. Who are you, and what have you done with Jeff Atwood?
I think abstraction here is a really poor choice of words for what you’re describing.
I also think you could’ve covered some of the pitfalls of using 3rd party libraries in your code, and how you need to abstract those out of the rest of your code for maintainability.
I dunno… maybe Coding Horror has jumped the shark. Who are you, and what have you done with Jeff Atwood?
It is interesting to see the lengths people will go to in order to justify working with stone knives and bearskins instead of power tools.
I suspect an overriding factor is the lack of experience with anything but the naked programming language they’ve chosen. These are probably also the same sorts of people who claim migration among programming languages and platforms is trivial. They simply do not have a professional level of experience invested in a given ecosystem.
We used to call these people trainees and junior programmers. But on the Internet nobody knows you’re a dog.
The big problems with this philosophy are:
Inter-library dependencies. This is a major problem with a lot of OSS frameworks. These libraries don’t worry about these dependencies and leave the worry up to you. So you end up with an encrytpion library that requires JRE 1.4 but some other library that requires JRE 1.6+. And then the headaches begin.
Libraries often try to be all things to all people. So you end up with tons of useless code bloat when all you want to do is encrypt a simple string. How many dozens of megabytes of code did you just add to your solution when you only needed one method out of the whole thing? Besides code bloat you are also dealing with learning bloat. You have to dig through all of the countless options to get to what you really want.
How do you know that the library you are using is really doing it better than you can do yourself? Unless you take the time to look at the specific implementation details of that EncryptStringforBrowser method, how do you know that it isn’t just using the same defaults that you used? You don’t. So taking the time to understand it is still required.
I don’t care what anyone wants to tell you, security through obscurity is not ridiculous. As the sole method of security it is. But as part of a layered approach it just gives one more hurdle that the attackers must crack. And if you use a well known library then they don’t have to work very hard to crack your code if there are known exploits. Many will likely beat me up on this but they are probably not understanding my point.
Overall I find libraries to be useful for most things. But their use does have its downsides.
@qwert
"So you do all of your coding in assembly?"
What?! And trust an assembler?!!!
Libraries might be useful in more cases if it didn’t take more time to make them work for you than it does to solve the problem yourself.
I believe that the reason that a lot of programmers opt for the “roll your own” method instead of using an existing library is that it makes them feel more like a true programmer, other than just another “code borrower” that they probably went to school with and made fun of going through their CS degree program.
I just felt the need to respond to this.
It’s a balancing act.
If you’re using a library that’s still using a method that’s now considered insecure, whose fault is it if your site is insecure? You may not even be fully aware it’s happening (that’s the point of abstraction isn’t it?). If you were down in the details you’d be aware of exactly what was going on, so if you do find it’s insecure you can both identify that you have a problem, and enable yourself to fix it (not always so with the abstraction).
There’s a flip side to that abstraction and sometimes it isn’t worth it. In the case of security it can be pretty clear cut many times, but many times you inherit design flaws, maintenance nightmares, etc, for an abstraction that only casually fits your problem. Sometimes it’s a win to roll your own, despite the existence of solutions.
sweet
I believe that the reason that a lot of programmers opt for the “roll your own” method instead of using an existing library is that it makes them feel more like a true programmer, other than just another “code borrower” that they probably went to school with and made fun of going through their CS degree program.
None the less, security over ego always wins the fight.
First?
That way a buffer overflow won’t imperil just your site, it will imperil tens of thousands of severs.
(And what it the world does Mitchell hanker after?)
This is very true.
Now talking about Cryptography, even if you are using a very popular and secure library, there is a chance that you screw things up of you don’t know cryptographic primitives.
The biggest factor is that the person writing the code, whether it be from scratch or using some library, should know atleast the basics of the field. Otherwise, you will see people encrypt data with the best encryption algorithm in the most secure chaining mode and then attach the key in plaintext with the data.
I completely agree that we ahould use standrd libraries for these kind of stuff, but I am just adding that to write secure code, get a developer who knows the naunces of security. That is in a way another layer of abstraction, isn’t it?
And then there are a bunch of people who don’t even use the primitives of the language. They write their own code!: http://www.diovo.com/2009/02/wrote-your-own-encryption-algorithm-duh/
Well, yes. Library code is good, good library code that’s being maintained by someone else is even better. We get the strong, debugged, field-tested code just sitting there.
What I wish more people I’ve worked with would remember is that, if needs be, we can write our own libraries. Finding variations on the same non-circular wheels repeated throughout projects is a waste of developer time, a functionality problem for our users and intensely frustrating for the maintainers. When you then find that a function is written on the assumption that the wheel is basically circular but has this kink under some circumstances…
When we can, use a decent pre-existing library. When we can’t, write our own library and use that - most problems aren’t unique.
@Taylor
"roll your own" also tends to come about when rolling your own is easier to think about than reading 100 pages of API documentation or guessing when no API documentation is available.
All programmers can think in programming primitives, it’s harder to think in someone else’s primitives.
Why are there so many web frameworks? Because it’s easier to think about parsing a string, and generating another string in response, then it is to learn the required structure of most of these frameworks. So people roll their own.
Whenver considering using a library that performs something so non-trivial, remember the Pragmatic warning: “Beware Evil Wizards”. Know your library in a truly Heinleinian way* before proceeding, or you’ll find yourself looking down the business end.
*“grok” to those who know the word, but not the book.
It’s interesting that you say “wrong layer of abstraction” instead of “not enough abstraction”.
Not once did you provide an example, or even mention that there are some cases where you want to work with less abstraction (see: performance).
Analogy FAIL.
Getting back to specifics: how can you stop programmers from working
at the wrong layer of abstraction? One solution would be to disallow
the .NET encryption primitives entirely. This is akin to Steve
Gibson’s holy crusade against raw socket programming in Windows XP.
Actually, Steve Gibson’s objection to the raw socket API was that exposing it would allow malware to be more dangerous. This is totally different to exposing an API which allows naive programmers to make mistakes.
Bravo, excellent post.
You’re correct: using a library is very DRY, and would have prevented the problems you experienced previously in the trilogy.
Perhaps the most useful thing of all, then, would be some form of central database of code libraries for a variety of languages.