<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Why wasn&#8217;t OAuth Vulnerability found earlier?</title>
	<atom:link href="http://blog.docuverse.com/2009/04/28/why-wasnt-oauth-vulnerability-found-earlier/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.docuverse.com/2009/04/28/why-wasnt-oauth-vulnerability-found-earlier/</link>
	<description>Don Park's Personal Blog</description>
	<lastBuildDate>Sun, 21 Aug 2011 19:05:53 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: donpark</title>
		<link>http://blog.docuverse.com/2009/04/28/why-wasnt-oauth-vulnerability-found-earlier/#comment-583</link>
		<dc:creator><![CDATA[donpark]]></dc:creator>
		<pubDate>Wed, 29 Apr 2009 04:21:18 +0000</pubDate>
		<guid isPermaLink="false">http://blog.docuverse.com/?p=263#comment-583</guid>
		<description><![CDATA[Matt, while I agree that other protocols had flaws of varying nature, uncovering of fundamental flaws like the OAuth one and DNS one are rare events, often resulting in industry-wide scramble.

Also, I don&#039;t think we should accept incidental trickles of flaw discoveries as the norm when there are actions we can take to improve the process.

IMO, it&#039;s the same with open source projects. OS participants are primarily focused on using, extending, or repurposing the project code which means while bugs are uncovered, security vulnerabilities are rarely found until attack incidents occur or by chance.

So I think some attention should be paid to finding ways or factors to introduce in grassroots initiatives and open source projects that encourages early detection of security vulnerabilities.]]></description>
		<content:encoded><![CDATA[<p>Matt, while I agree that other protocols had flaws of varying nature, uncovering of fundamental flaws like the OAuth one and DNS one are rare events, often resulting in industry-wide scramble.</p>
<p>Also, I don&#8217;t think we should accept incidental trickles of flaw discoveries as the norm when there are actions we can take to improve the process.</p>
<p>IMO, it&#8217;s the same with open source projects. OS participants are primarily focused on using, extending, or repurposing the project code which means while bugs are uncovered, security vulnerabilities are rarely found until attack incidents occur or by chance.</p>
<p>So I think some attention should be paid to finding ways or factors to introduce in grassroots initiatives and open source projects that encourages early detection of security vulnerabilities.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matt Brubeck</title>
		<link>http://blog.docuverse.com/2009/04/28/why-wasnt-oauth-vulnerability-found-earlier/#comment-582</link>
		<dc:creator><![CDATA[Matt Brubeck]]></dc:creator>
		<pubDate>Wed, 29 Apr 2009 03:24:06 +0000</pubDate>
		<guid isPermaLink="false">http://blog.docuverse.com/?p=263#comment-582</guid>
		<description><![CDATA[I don&#039;t think it&#039;s that complicated.  There have been all manner of crypto protocols and security protocols that have been in use for years before critical flaws were discovered.  Some were developed by standards bodies or subject to academic peer review.  The fact is that any flaws left in a system after it&#039;s been reviewed and revised and published can be quite hard to see, even if they&#039;re obvious after someone points them out.]]></description>
		<content:encoded><![CDATA[<p>I don&#8217;t think it&#8217;s that complicated.  There have been all manner of crypto protocols and security protocols that have been in use for years before critical flaws were discovered.  Some were developed by standards bodies or subject to academic peer review.  The fact is that any flaws left in a system after it&#8217;s been reviewed and revised and published can be quite hard to see, even if they&#8217;re obvious after someone points them out.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter Keane</title>
		<link>http://blog.docuverse.com/2009/04/28/why-wasnt-oauth-vulnerability-found-earlier/#comment-581</link>
		<dc:creator><![CDATA[Peter Keane]]></dc:creator>
		<pubDate>Wed, 29 Apr 2009 01:25:31 +0000</pubDate>
		<guid isPermaLink="false">http://blog.docuverse.com/?p=263#comment-581</guid>
		<description><![CDATA[I recently implemented my first OAuth client and had a slightly uneasy feeling that there was a bit of magic -- I couldn&#039;t cleary see how it was truly secure.  Fact is, it was pretty darn close -- the hole was never exploited (that we know) and steps are being taken to close that hole.

That said, a simple fix will still leave a bit of &quot;magic:&quot; there is an authentication equivalency that is not being addressed (in OAuth terms, that user@consumer == user@service_provider) by way of a properly out-of-band mechanism.  I would prefer to see that hole sewn up more definitively -- essntially &quot;whitelisting good guys&quot; rather than &quot;blacklisting bad guys&quot; (which can become a game of whack-a-mole). I should note that many knowledgeable folks on the list feel the proposed fix is adequate.  Two-legged OAuth, a less common use than the typical Three-legged flavor, is an excellent protocol (the exploit was discovered only in the Three-legged variety), and I suspect we&#039;ll see more adoption as a stand-in for HTTP Basic &amp; HTTP Digest authentication.]]></description>
		<content:encoded><![CDATA[<p>I recently implemented my first OAuth client and had a slightly uneasy feeling that there was a bit of magic &#8212; I couldn&#8217;t cleary see how it was truly secure.  Fact is, it was pretty darn close &#8212; the hole was never exploited (that we know) and steps are being taken to close that hole.</p>
<p>That said, a simple fix will still leave a bit of &#8220;magic:&#8221; there is an authentication equivalency that is not being addressed (in OAuth terms, that user@consumer == user@service_provider) by way of a properly out-of-band mechanism.  I would prefer to see that hole sewn up more definitively &#8212; essntially &#8220;whitelisting good guys&#8221; rather than &#8220;blacklisting bad guys&#8221; (which can become a game of whack-a-mole). I should note that many knowledgeable folks on the list feel the proposed fix is adequate.  Two-legged OAuth, a less common use than the typical Three-legged flavor, is an excellent protocol (the exploit was discovered only in the Three-legged variety), and I suspect we&#8217;ll see more adoption as a stand-in for HTTP Basic &amp; HTTP Digest authentication.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

