Sorry. I forgot to add it becomes a race if and only if the TS is smart enough to invalidate code after first use.
Phil Sent from my phone. On 2011-04-01, at 18:07, Skylar Woodward <sky...@kiva.org> wrote: > I'm going to summarize (hopefully faithfully) the attacks referenced here, > with the hope of attempting to sum up the scope of attacks being documented. > > On Apr 1, 2011, at 1:29 PM, Francisco Corella wrote: > >> Skylar, >> >>> Right, but just so we are clear, the only case you are >>> discussing here is the MITM attack, which George, I and >>> others have recently outlined. >> >> There several flavors of MITM attacks, and a passive attack. >> See > > This document describes the MITM attack, similar to the one I just described. > Furthermore, it goes on to describe the vulnerabilities of users on unsecured > or public networks (particularly WiFi and malicious rouge WiFi access points) > to MITM attacks. > >> http://www.ietf.org/mail-archive/web/oauth/current/msg04894.html, > > This document references the above attack, but emphasizes the risk to > applications using a provider service for Authentication who also fail to > secure their application (including redirect) with TLS. > >> http://www.ietf.org/mail-archive/web/oauth/current/msg04900.html, > > This document briefly describes attacks from the first document and mentions > also a "passive" attack where the attacker "sniffs" the auth code rather than > performing a MITM attack. The attack can only be successful if providers fail > to revoke tokens/sessions for which the provider sees a replay of auth codes. > However, for all implementations (again, assuming no TLS on the callback) it > can "annoy" the user by disrupting or breaking their sessions by use of > auth-code replay. > >> and the last two paragraphs of page 4 of >> http://pomcor.com/techreports/DoubleRedirection.pdf. > > So for all attacks, I assume you would agree that risk is all but mitigated > for applications running on a trusted corporate intranet (where Bob and > client C are within the corporate intranet) or VPN on a public network. In > this case, there would be no risk of MITM attacks unless the corporate > network itself was compromised (in which case, the victim may have larger > issues). Also, for the "cafe attack" the risks would be nominal for users > accessing the public service through a protective VPN (in which case the MITM > attack would be much more expensive/difficult). > > I'm not trying to downplay the validity of any of the attacks, I'm just > trying to understand the cases being described and contexts which will most > likely bring attacks to bear. I do feel like in most cases the security of > the user's computer or the client app itself is more in question than the > security of the redirect step (getting back to the difficult debate of > scope/role of the OAuth spec). > > skylar _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
