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.
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.
You are probably right. I would be pleased to be directed to some good sources about cryptography.
With the exception of vector #6, this is pretty much a list of implementation flaws, not protocol flaws. It's as if he's trying to say that the protocol isn't written defensively enough or foolproof enough for implementors, and he might have a good point if he simply said that, but he never did. Even with an OAuth library for the nuts and bolts, to implement an OAuth2 authorization server requires grokking the spec.…
> this is pretty much a list of implementation flaws, not protocol flaws
I can agree with that but problems outlined are very common so it doesn't really matter. Say, Facebook is major oauth2 provider and doesn't follow most of the spec. As well as lots of popular libraries.
Ah, but if only people switched to Persona. If only people looked into it more than 5 minutes and realized that Persona is still maintained and is by far the best way to do authentication on the web. Really, the most correct protocol out there. But then of course, if only Mozilla had a marketing team worth a damn and didn't make it look like they gave up on the whole thing in the first place, we wouldn't have this si…
Ah, but if only people switched to Persona. If only people looked into it more than 5 minutes and realized that Persona is still maintained and is by far the best way to do authentication on the web. Really, the most correct protocol out there. But then of course, if only Mozilla had a marketing team worth a damn and didn't make it look like they gave up on the whole thing in the first place, we wouldn't have this si…
I agree with you. I looked into Persona to implement an SSO for our products (provider and client). I've never been able to understand OAuth in the context of an authentication mechanism so I left it. However, Persona has very poor library support, especially for providers. The support channels are also very small, so you're not likely to find other people fixing the same issues. I ended up just hacking an OpenID pro…
If you want to talk more about persona and try to promote it (brand new mailing list):
persona.advocacy atsign librelist dot com
send an email to subscribe, the first email will be
Ah, but if only people switched to Persona. If only people looked into it more than 5 minutes and realized that Persona is still maintained and is by far the best way to do authentication on the web. Really, the most correct protocol out there. But then of course, if only Mozilla had a marketing team worth a damn and didn't make it look like they gave up on the whole thing in the first place, we wouldn't have this si…
Well, you have convinced 1 person to look into it. Whats the best article, blogpost to read.
If you want to talk more about persona and try to promote it (brand new mailing list):
persona.advocacy atsign librelist dot com
send an email to subscribe, the first email will be
Well, you have convinced 1 person to look into it. Whats the best article, blogpost to read.
Unfortunately, like scott said above, persona has very poor overall support. The best resources are the official ones: https://developer.mozilla.org/en-US/Persona I strongly believe in the protocol, but I have stopped believing in Mozilla to actually do something with it. They have absolute technical gold (yes, it has a couple of issues, they are minor overall) and they just aren't doing anything with it . I still en…
If you want to talk more about persona and try to promote it (brand new mailing list):
persona.advocacy atsign librelist dot com
send an email to subscribe, the first email will be
With the exception of vector #6, this is pretty much a list of implementation flaws, not protocol flaws. It's as if he's trying to say that the protocol isn't written defensively enough or foolproof enough for implementors, and he might have a good point if he simply said that, but he never did. Even with an OAuth library for the nuts and bolts, to implement an OAuth2 authorization server requires grokking the spec.…
> this is pretty much a list of implementation flaws, not protocol flaws I can agree with that but problems outlined are very common so it doesn't really matter. Say, Facebook is major oauth2 provider and doesn't follow most of the spec. As well as lots of popular libraries.
You're probably right; spec conformance is a problem. What should be done about it? If the spec itself isn't all that bad, then we should try to improve implementations. Maybe tools can be developed to help detect implementation flaws. Or if the letter of the spec is the problem, but the protocol/framework itself is good, then why not rewrite an alternative spec, similar to what was done recently for HTTP/1.1?
> this is pretty much a list of implementation flaws, not protocol flaws I can agree with that but problems outlined are very common so it doesn't really matter. Say, Facebook is major oauth2 provider and doesn't follow most of the spec. As well as lots of popular libraries.
You're probably right; spec conformance is a problem. What should be done about it? If the spec itself isn't all that bad, then we should try to improve implementations. Maybe tools can be developed to help detect implementation flaws. Or if the letter of the spec is the problem, but the protocol/framework itself is good, then why not rewrite an alternative spec, similar to what was done recently for HTTP/1.1?
The spec should be robust against the possibility of implementation errors that result in the system being less secure. This is distinct from the possibility of implementation errors that simply result in the code not working at all or being obviously broken. You can't prevent those, but you also don't need to. The point is that subtle implementation errors should be ruled out as much as possible.
This is a common criterion in cryptography, against which systems and primitives are judged.
Well, you have convinced 1 person to look into it. Whats the best article, blogpost to read.
Unfortunately, like scott said above, persona has very poor overall support. The best resources are the official ones: https://developer.mozilla.org/en-US/Persona I strongly believe in the protocol, but I have stopped believing in Mozilla to actually do something with it. They have absolute technical gold (yes, it has a couple of issues, they are minor overall) and they just aren't doing anything with it . I still en…
Seams like a cool system. What do you think about the new Fido standards, U2F and UAF. They solve the same problem but without a third party.
I agree with you. I looked into Persona to implement an SSO for our products (provider and client). I've never been able to understand OAuth in the context of an authentication mechanism so I left it. However, Persona has very poor library support, especially for providers. The support channels are also very small, so you're not likely to find other people fixing the same issues. I ended up just hacking an OpenID pro…
If you want to talk more about persona and try to promote it (brand new mailing list): persona.advocacy atsign librelist dot com send an email to subscribe, the first email will be
I don't see this going anywhere unless you either have Mozilla's endorsement or a userbase to work with already.