OpenID-Connect (which is really OAuth2 with a specified auth/profile flow)
OAuth1, OAuth2, OAuth..? (2013)
11–20 of 50 posts
Re: OAuth1, OAuth2, OAuth..? (2013)
#12Article looks familiar, and was published March 1, 2013.
Thanks, we updated the title.
Re: OAuth1, OAuth2, OAuth..? (2013)
#13Earlier quoted context omitted.
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.
I only partly agree with you. Every developer does not need to know exactly how HTTPS encryption algorithms work, just whether they are secure or not.
"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.
Re: OAuth1, OAuth2, OAuth..? (2013)
#14I've written an OAuth2 server implementation and to be honest, I still don't really understand why people use OAuth2 instead of OAuth1.0a. The minimum amount of work you have to do to write an implementation that complies with the spec leaves you open to all sorts of security issues (as Homakov continues to detail), no two providers implement the same parts of the spec so writing clients isn't really all that easy, and the "security" features don't really seem all that secure. For example, refresh tokens, what the fuck? If an attacker can steal your access token why would you assume that your refresh tokens are safe? How is it ok to say "well, even if your access token is stolen at least it will expire eventually, so don't worry"?
/rant.
Re: OAuth1, OAuth2, OAuth..? (2013)
#15Earlier quoted context omitted.
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.
Re: OAuth1, OAuth2, OAuth..? (2013)
#16My understanding from my research into OAUTH2 is that most of the vulnerabilities in it are only issues in a naive implementation. They can be made secure, but it's not easy and you have to know to do it in the first place.
Doesn't OpenID Connect address those issues? I know that's what Google is using now.
Re: OAuth1, OAuth2, OAuth..? (2013)
#17Earlier quoted context omitted.
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.
I only partly agree with you. Every developer does not need to know exactly how HTTPS encryption algorithms work, just whether they are secure or not.
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.
Again, it's not a binary.
Re: OAuth1, OAuth2, OAuth..? (2013)
#18Earlier quoted context omitted.
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.
I only partly agree with you. Every developer does not need to know exactly how HTTPS encryption algorithms work, just whether they are secure or not.
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.
Re: OAuth1, OAuth2, OAuth..? (2013)
#19This 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.
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.
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.
Re: OAuth1, OAuth2, OAuth..? (2013)
#20[deleted]