On Fri, Sep 24, 2010 at 9:06 AM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
> Validating the signed data delivered with the request is as much magic as > the current 1.0 approach. Go write the validation rules and see. > Done that (for the specific case of Salmon). The only trick is to write the code so that if the message were delivered via a note tied to a rock thrown through your window, it would have the same security properties as the ones delivered via HTTP. This is very amenable to static analysis. Is there a specific attack vector that we could discuss that you're worried about? > > I'm getting really tired of this argument because it is not grounded in > reality. Any attempt to compare the HTTP request to what was signed, whether > it is sent with the request or not, is as difficult. Sending the signed data > just makes it easier for the server to make bad assumptions and be flexible > in an insecure way. > > EHL > > On Sep 24, 2010, at 10:51, "Justin Richer" <jric...@mitre.org> wrote: > > >>> I think that any signature method that we end up using needs to rely > >>> less on magic and anecdote and more on explicit declaration. > >> > >> This is certainly correct ... > >> > >> > >>> I think > >>> that Brian Eaton's approach of sending the bare string that was > >>> signed, > >>> which was also a JSON element that could be parsed and validated, > >>> was an > >>> essential simplification. > >> > >> ... but this does not follow. The signer can specify what was signed > >> without sending the data... > >> > >>> Even OpenID states which of the parameters on > >>> the request were signed, which makes it easier to validate. > >> > >> ... as in this pattern. There are some other examples of elements of > >> the signed object being conditionally included: > >> 1. HTTP Digest authentication [1] > >> 2. The IKEv2 key exchange messages [2] > > > > And I'm marginally OK with either pattern, though I think that the > > former is a much cleaner way to do it. I believe either case to be > > worlds better than the OAuth 1.0 method, which has caused countless > > problems. I actually had to help someone debug between sending that > > first email and this one, so I can attest that the problem has not gone > > away! :) > > > >> As has been pointed out before, there is a security risk in sending > >> the signed request data itself (as opposed to metadata that allows the > >> recipient to reconstruct the data), because the recipient can choose > >> not to verify the binding between the signed data and the request. > > > > Yes, there is certainly a risk if someone just checks the signature and > > does not verify the content of the message. This is a bad implementation > > of an authorization system, to be sure, and it's an issue that people > > need to be aware of. But simply signing metadata doesn't completely > > solve the problem, either. In both cases there can be parameters that > > are outside of the signed request that need to be checked and treated > > appropriately. > > > > -- Justin > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
