What about temporary credentials across a local link between controlled systems? My point is just that there are cases where the usual leakage culprits (browsers, proxies, caches, logs) don't apply.
It's also a bad idea to not use two-way TLS, and it's arguably a bad idea to look at anything on the web without using TLS to begin with, but we still do. It's all about the tradeoff between security of a system and the usability and usefulness of a system. There's an old adage that the most secure computer is powered off and unplugged. :) I think it's very important to strike an appropriate balance. -- Justin ________________________________________ From: Phil Hunt [phil.h...@oracle.com] Sent: Thursday, March 10, 2011 1:15 PM To: Richer, Justin P. Cc: William J. Mills; Lukas Rosenstock; OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft -1. It is a BAD security practice to pass credentials in URLs. Avoid it. Phil phil.h...@oracle.com On 2011-03-10, at 10:07 AM, Richer, Justin P. wrote: > Ah, here we run into the classic argument of usability vs. security, in which > usability will win every single time in practice. If we don't define at least > a reasonable way to do this within the scope of OAuth, that's not going to > stop people from doing it. It's just going to make people do it in a million > different ways, each with their own unique problems that nobody's thought of. > At least this way, we can enable it and have a real discussion about the > security considerations. There are valid and valuable places where putting > credentials in the URL is a reasonable security tradeoff. Not everything > functions over the public internet as well, and the security considerations > are different in these other environments. > > In short: yes, it's necessary and good to do this. > > -- Justin > ________________________________________ > From: William J. Mills [wmi...@yahoo-inc.com] > Sent: Thursday, March 10, 2011 12:59 PM > To: Richer, Justin P.; Lukas Rosenstock > Cc: Brian Eaton; OAuth WG > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > > Yeah, but there are serious security problems with credentials in the URL, is > it really worth it in light of those problems? > > ________________________________ > From: "Richer, Justin P." <jric...@mitre.org> > To: Lukas Rosenstock <l...@lukasrosenstock.net>; William J. Mills > <wmi...@yahoo-inc.com> > Cc: Brian Eaton <bea...@google.com>; OAuth WG <oauth@ietf.org> > Sent: Thursday, March 10, 2011 9:49 AM > Subject: RE: [OAUTH-WG] OAuth Bearer Token draft > > Yes, there are many development setups where all you can reasonably access is > the URL to get. It's also much simpler to make use of the well-supported > syntax helpers for query parameters instead of relying on new, custom > formatting for newly-defined headers. The bearer token makes this simple by > just having the value of the token, but other schemes have their own > name/value pair formats and encodings that will inevitably cause hiccups. > > -- Justin > ________________________________________ > From: Lukas Rosenstock > [l...@lukasrosenstock.net<mailto:l...@lukasrosenstock.net>] > Sent: Thursday, March 10, 2011 11:49 AM > To: William J. Mills > Cc: Brian Eaton; Richer, Justin P.; OAuth WG > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > > JSON-P (callback) works with <script> tags where no parameters can be set; > this is used a lot in web applications that want to consume 3rd party APIs > directly on the client side. So, yes, an alternative for the Authorization > header is required - a.f.a.i.k this use case was one of the driving forces > behind WRAP and bearer tokens. > > 2011/3/9 William J. Mills > <wmi...@yahoo-inc.com<mailto:wmi...@yahoo-inc.com><mailto:wmi...@yahoo-inc.com<mailto:wmi...@yahoo-inc.com>>> > Is there really a need going forward for anything beyond using the > Authorization header? Do we have clients out there that just can't set that > header? Putting bearer tokens in query arguments is a very bad idea for many > reasons, and in form variables has it's own set of badness (although not to > the same level). > > -bill > > > > _______________________________________________ > 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
