<?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/"
		>
<channel>
	<title>Comments on: Issues with a FOAF-based Authentication System</title>
	<atom:link href="http://www.pipian.com/blog/2008/09/05/issues-with-foaf-authentication/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.pipian.com/blog/2008/09/05/issues-with-foaf-authentication/</link>
	<description>A weblog about the mysteries and musings found in everyday life.</description>
	<lastBuildDate>Thu, 03 Dec 2009 18:18:58 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Henry Story</title>
		<link>http://www.pipian.com/blog/2008/09/05/issues-with-foaf-authentication/comment-page-1/#comment-8603</link>
		<dc:creator>Henry Story</dc:creator>
		<pubDate>Sat, 06 Sep 2008 06:18:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.pipian.com/?p=51#comment-8603</guid>
		<description>Find me a protocol that is not open to user stupidity? Have you ever tried to doing internet transactions? They ask you for the number on a credit card. Something the credit vendor could then just reuse and make a sale elsewhere... So my point is that in so far as your problem is real, it applies to all protocols.</description>
		<content:encoded><![CDATA[<p>Find me a protocol that is not open to user stupidity? Have you ever tried to doing internet transactions? They ask you for the number on a credit card. Something the credit vendor could then just reuse and make a sale elsewhere&#8230; So my point is that in so far as your problem is real, it applies to all protocols.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pipian</title>
		<link>http://www.pipian.com/blog/2008/09/05/issues-with-foaf-authentication/comment-page-1/#comment-8590</link>
		<dc:creator>Pipian</dc:creator>
		<pubDate>Fri, 05 Sep 2008 21:53:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.pipian.com/?p=51#comment-8590</guid>
		<description>You&#039;re absolutely right that this is a social problem, but many individuals may be leaving the keys in the hands of some &#039;trustworthy company,&#039; not unlike how we trust the credit card companies, merchant services, vendors, and banks to all keep the keys locked up tight so that the other four don&#039;t end up losing money due to fraud.  The problem isn&#039;t necessarily that users aren&#039;t secure as opposed to not necessarily having the option to BE secure for various reasons (say, LiveJournal users using their FOAF export).  Furthermore, unlike the key examples, this isn&#039;t a threat to just the client, but also to the server relying on the correct individual at the other end.  If Bob has been granted wide-access on a service by a company, and his web host of choice gets hacked with a zero-day exploit, it may actually put the company at risk as much as Bob, even though Bob took proper precautions.

Granted, a private key can assist this, but the fact remains that FOAF+SSL requires the FOAF file to have the correct signature.  Just because Bob uses a USB key doesn&#039;t mean that someone can&#039;t hack the FOAF file to point to their OWN key&#039;s signature, so as to gain access to Bob&#039;s account.</description>
		<content:encoded><![CDATA[<p>You&#8217;re absolutely right that this is a social problem, but many individuals may be leaving the keys in the hands of some &#8216;trustworthy company,&#8217; not unlike how we trust the credit card companies, merchant services, vendors, and banks to all keep the keys locked up tight so that the other four don&#8217;t end up losing money due to fraud.  The problem isn&#8217;t necessarily that users aren&#8217;t secure as opposed to not necessarily having the option to BE secure for various reasons (say, LiveJournal users using their FOAF export).  Furthermore, unlike the key examples, this isn&#8217;t a threat to just the client, but also to the server relying on the correct individual at the other end.  If Bob has been granted wide-access on a service by a company, and his web host of choice gets hacked with a zero-day exploit, it may actually put the company at risk as much as Bob, even though Bob took proper precautions.</p>
<p>Granted, a private key can assist this, but the fact remains that FOAF+SSL requires the FOAF file to have the correct signature.  Just because Bob uses a USB key doesn&#8217;t mean that someone can&#8217;t hack the FOAF file to point to their OWN key&#8217;s signature, so as to gain access to Bob&#8217;s account.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Henry Story</title>
		<link>http://www.pipian.com/blog/2008/09/05/issues-with-foaf-authentication/comment-page-1/#comment-8575</link>
		<dc:creator>Henry Story</dc:creator>
		<pubDate>Fri, 05 Sep 2008 18:05:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.pipian.com/?p=51#comment-8575</guid>
		<description>Well of course if you leave the keys to your house under the door mat, anyone can come in and answer your telephone calls. Clearly this is not a problem with the key, this is a problem with how people make use of the key. Similarly if you have an army to protect your country, but they don&#039;t guard the frontier, then people can invade easily. That&#039;s not a problem with the army, but with how they are trained. Similarly in this case. If people don&#039;t protect their passwords giving access to their web server, then that does not say anything about the protocol, just that people are ignorant of security. This problem can&#039;t be solved by changing the protocol therefore, but has to be changed in other ways, either by education, or by making it very difficult for people to loose their information.

You can improve the security of a web server dramatically by only allowing access via SSL, and having SSL get its key from a USB key containing an impossible to remove private key that would encrypt the communication. This costs hardly anything nowadays. If someone looses their key, they would notice it and be able to call the alarm. You can make things more secure still quite easily. It is just a matter for these services to be rolled out. Furthermore that could be the same key your browser uses to encrypt the foaf+ssl connection in that protocol.

In the case of OpenId, which is more complicated, there are more places of failure, and so more ways for things to go wrong. That is a problem for it. But you also have to see how things stand at present, with people giving out their passwords to gmail to facebook in order to export easily their social network. And as far as that goes, openid is already a big improovement.</description>
		<content:encoded><![CDATA[<p>Well of course if you leave the keys to your house under the door mat, anyone can come in and answer your telephone calls. Clearly this is not a problem with the key, this is a problem with how people make use of the key. Similarly if you have an army to protect your country, but they don&#8217;t guard the frontier, then people can invade easily. That&#8217;s not a problem with the army, but with how they are trained. Similarly in this case. If people don&#8217;t protect their passwords giving access to their web server, then that does not say anything about the protocol, just that people are ignorant of security. This problem can&#8217;t be solved by changing the protocol therefore, but has to be changed in other ways, either by education, or by making it very difficult for people to loose their information.</p>
<p>You can improve the security of a web server dramatically by only allowing access via SSL, and having SSL get its key from a USB key containing an impossible to remove private key that would encrypt the communication. This costs hardly anything nowadays. If someone looses their key, they would notice it and be able to call the alarm. You can make things more secure still quite easily. It is just a matter for these services to be rolled out. Furthermore that could be the same key your browser uses to encrypt the foaf+ssl connection in that protocol.</p>
<p>In the case of OpenId, which is more complicated, there are more places of failure, and so more ways for things to go wrong. That is a problem for it. But you also have to see how things stand at present, with people giving out their passwords to gmail to facebook in order to export easily their social network. And as far as that goes, openid is already a big improovement.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
