This article is just technical enough for me. As a developer implementing security can be a pain in the ass. All I wan't is someone to tell if a protocol is secure, and get done with it.
I don't know about that — it helps to have more than superficial knowledge of the topic at hand so that you can adequately assess rants such as this one.
Personally, while I feel that Igor Homakov has done good work, this article is the product of frustration and is a disservice to its audience. Most if not all of his criticisms of OAuth 2 come down to implementation problems, and a more positive contribution would be an implementers' guide or a threat model document. For example, https://tools.ietf.org/html/rfc6819 and http://leastprivilege.com/2013/03/15/common-oauth2-vulnerabi....
That's the kind of attitude that leads to massive security flaws. Understanding security is more than just "yes or no". You must understand the concepts. If you don't, stop professionally writing software, because you're doing something irresponsible that will do real harm to real people.
Agreed, but there is a difference between understanding, let's say, how PKI works and how it applies to HTTPS vs knowing how to implement AES. Sometimes, we just need to know that SSL 3 is broken, and don't need to know the exact details. All we then need to know is to stop using it.
My comment was more generalized, as it was responding to a general comment.
However, I will say that HTTPS is not too complicated to understand and that it's not a magic bullet.
You still need to understand, for example, how a certificate can be compromised and what the pros/cons are of different implementations. It's not a simple "yes or no", even though it's close.
It sounds like maybe you don't understand the concepts.
Of course you're right that most people don't need to know exactly how encryption algorithms work. But, everybody needs to know what they do -- and what they don't do! That's a deeper level understanding than simply knowing if they're "secure" or not.
For example, too many people think that encryption gives you security. It does not. Encryption can provide confidentiality, but only if you also have integrity and authentication. Those three things are just the beginning of security.
One of the implications is that if you're using a self-signed certificate for HTTPS, you might as well not bother encrypting. If you don't reject a certificate lacking a verified signature, then you can't know that you aren't talking to a MITM instead of the server you think you're accessing. A MITM can trivially decrypt all your data, so why bother encrypting in the first place if you don't verify certs? Too many people ignore the certificates because they don't understand what encryption really gets them.
Many people also discount that danger because they don't understand how trivially easy MITM attacks can be. ARP spoofing is not hard. Some networking equipment is getting better at preventing it, but you can't always count on it. In short, it's best to assume that anybody else with a laptop in your local coffee shop can see _and modify_ all network packets you send. They don't necessarily have to break the wireless encryption to see them, either, so that won't keep you safe.
"Secure or not" is not a meaningful distinction. "Secure" means a lot of different properties which may be of varying importance to different people and applies to the whole system, not individual components. So the only meaningful interpretation of 'secure' for a subcomponent is "Does it achieve the security properties it aims to?". It does not excuse from learning what those properties are, what they mean, and their implications for the security of the system as a whole.
Valid point. Even encryption is only "secure" for a limited time. I could sniff the traffic, store the data and wait until the encryption is crackable. For most transactions that is good enough as our passwords are probably not relevant in 10 years. For some transactions it may not be enough because you probably would have the same bank account in 10 years. Granted the cost to capture and save for a later date probably outweighs the potential to exploit.
At the same time I would not expect a front end JS/CSS developer to know the specifics of the entire system, only the parts of his/her subsystem. That is to say they should know XSS/CSRF like the back of their hand, but probably don't need to fully understand a stack overflow. On the other hand if you write C/C++ or any other low/mid level language XSS probably means nothing to you and stack overflow is highly important.
See my comment above. There's a lot more to protecting a site from man-in-the-middle attacks than enabling HTTPS.
The most important things people need to know are the pros/cons of different types of certificates, how to keep certificates safe, and whether they have a vulnerable SSL library installed.
To the downvoters: if you stick your head in the sand, you'll do things like using MD5 for password hashing and logging into remote servers as root. I see basic mistakes like that all the time.
I'll reiterate (and this is a general comment, not necessarily about HTTPS): if you aren't willing to understand how software works and how people attack it, don't write it professionally. It's part of your job and your responsibility to your customers and their users.
When systems are cracked, it can leak financial info, passwords, addresses, children's names, medical info, etc., etc. You may have a totally innocuous site that helps someone get into one of your user's more sensitive accounts.
Security is really important and failing to understand it can ruin people's lives. I've personally seen it happen.
It worries me that saying something as simple and unassailable as "understand the security implications of your code" got downvoted on a "hacker" site so many times.
"Understanding security is more than just "yes or no". You must understand the concepts. If you don't, stop professionally writing software, because you're doing something irresponsible that will do real harm to real people."
Which is a very direct and negative comment. Not all software significantly touches on security. People write one off programs for generating musical compositions, one off pieces of data analysis. Proof of concepts that aren't designed to ship and any number of non-internet connected programs where the security considerations are less significant.
If you didn't mean those applications, then your comment amounts to "people writing security sensitive software should be mindful of security". Which is so redundant as to be meaningless.
Telling people "you have no right to be programming" on a hacker forum is unlikely to make you many friends.
Yes, I was being direct and negative. I was responding to someone who wanted to be a developer and not have to understand security. That kind of attitude/culture is what makes so many thousands of widely-used applications vulnerable. Security shouldn't be an afterthought. People trust us to write secure software, and few of us do.
The key word in my comment was "professionally". I'm not telling someone experimenting for fun to learn detailed security implications. I'm talking to someone who is charging someone (clients or employers) for their work.
And what I said is, sadly, not so redundant as to be meaningless because I was responding to someone who said "I don't want to be mindful of security, just tell me if [XYZ] works." So obviously it DID need to be said!
