<?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: The Yubikey</title>
	<atom:link href="http://etbe.coker.com.au/2010/03/15/yubikey/feed/" rel="self" type="application/rss+xml" />
	<link>http://etbe.coker.com.au/2010/03/15/yubikey/</link>
	<description>Linux, politics, and other interesting things</description>
	<lastBuildDate>Wed, 08 Feb 2012 14:45:45 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: etbe</title>
		<link>http://etbe.coker.com.au/2010/03/15/yubikey/comment-page-1/#comment-24485</link>
		<dc:creator>etbe</dc:creator>
		<pubDate>Tue, 23 Mar 2010 04:41:27 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=1873#comment-24485</guid>
		<description>Barak:  Good point.

I should have said that the principle in question applies for all methods of communication other than some of those which rely on a challenge from the server.

Some challenge-response systems won&#039;t be safe against such an attack either, if you don&#039;t have public key encryption and you have the same algorithm and data set used by all servers then any compromised server should be able to gain credentials for others.  The problem is that doing this properly requires more compute power on the client side - which can be a problem for a smart-card or other limited device.

Maxim: I&#039;ve replaced the &quot;spambot&quot; message with one that makes things easier for humans.</description>
		<content:encoded><![CDATA[<p>Barak:  Good point.</p>
<p>I should have said that the principle in question applies for all methods of communication other than some of those which rely on a challenge from the server.</p>
<p>Some challenge-response systems won&#8217;t be safe against such an attack either, if you don&#8217;t have public key encryption and you have the same algorithm and data set used by all servers then any compromised server should be able to gain credentials for others.  The problem is that doing this properly requires more compute power on the client side &#8211; which can be a problem for a smart-card or other limited device.</p>
<p>Maxim: I&#8217;ve replaced the &#8220;spambot&#8221; message with one that makes things easier for humans.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Barak A. Pearlmutter</title>
		<link>http://etbe.coker.com.au/2010/03/15/yubikey/comment-page-1/#comment-24482</link>
		<dc:creator>Barak A. Pearlmutter</dc:creator>
		<pubDate>Mon, 22 Mar 2010 10:46:44 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=1873#comment-24482</guid>
		<description>etbe: &quot;If you have server A and server B accepting the same login credentials then if you login to server A which has been compromised then that server could instead of authenticating you use the credentials you supplied to login to server B. This applies for all methods of authentication.&quot;  That is not true.  For instance, challenge/response authentication, where the challenge starts with the name of the server, would not be vulnerable to this.</description>
		<content:encoded><![CDATA[<p>etbe: &#8220;If you have server A and server B accepting the same login credentials then if you login to server A which has been compromised then that server could instead of authenticating you use the credentials you supplied to login to server B. This applies for all methods of authentication.&#8221;  That is not true.  For instance, challenge/response authentication, where the challenge starts with the name of the server, would not be vulnerable to this.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: etbe</title>
		<link>http://etbe.coker.com.au/2010/03/15/yubikey/comment-page-1/#comment-24466</link>
		<dc:creator>etbe</dc:creator>
		<pubDate>Thu, 18 Mar 2010 21:10:49 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=1873#comment-24466</guid>
		<description>Michael: You can do equivalent OTP calculations on a laptop or PDA but it takes more typing and requires more things to carry around.

Barak: It&#039;s not a OTP.  If you have server A and server B accepting the same login credentials then if you login to server A which has been compromised then that server could instead of authenticating you use the credentials you supplied to login to server B.  This applies for all methods of authentication.  If server A authenticates you and if the authentication server has not been compromised then server B will not accept a login with the same code from the Yubikey.

Sure everything the Yubikey does could be done with some software and a USB storage device.  The point of the Yubikey is that it&#039;s small enough and compatible enough that you can carry it everywhere.

Maxim: If you are accused of being a &quot;spambot&quot; then you missed the arithmetic question.  I don&#039;t like the way it handles errors in that regard and plan to change it.</description>
		<content:encoded><![CDATA[<p>Michael: You can do equivalent OTP calculations on a laptop or PDA but it takes more typing and requires more things to carry around.</p>
<p>Barak: It&#8217;s not a OTP.  If you have server A and server B accepting the same login credentials then if you login to server A which has been compromised then that server could instead of authenticating you use the credentials you supplied to login to server B.  This applies for all methods of authentication.  If server A authenticates you and if the authentication server has not been compromised then server B will not accept a login with the same code from the Yubikey.</p>
<p>Sure everything the Yubikey does could be done with some software and a USB storage device.  The point of the Yubikey is that it&#8217;s small enough and compatible enough that you can carry it everywhere.</p>
<p>Maxim: If you are accused of being a &#8220;spambot&#8221; then you missed the arithmetic question.  I don&#8217;t like the way it handles errors in that regard and plan to change it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Maxim</title>
		<link>http://etbe.coker.com.au/2010/03/15/yubikey/comment-page-1/#comment-24451</link>
		<dc:creator>Maxim</dc:creator>
		<pubDate>Thu, 18 Mar 2010 11:26:43 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=1873#comment-24451</guid>
		<description>etbe: You&#039;re welcome :) I was asking because I am the maintainer for some of these packages for Fedora, and I know for sure we have pam_yubico, as well as ykpers and libyubikey in Fedora. I&#039;m considering packaging YubiPAM, but I lack time and development seems a bit slow on it. Oh, I&#039;m having a hard time with your spam stuff. OpenID refuses to work and keeps calling me a spambot :)

Barak: pam_usb does that, sort of. That project has pretty slow development though. I even think pam_usb got dropped from Fedora for it. The limitation of such a setup would be though, that it would not work - or at least: not easily - over a network. Yubikeys are designed to work over the network. Mitm attacks are an issue for a lot of other network authentication mechanisms too. I a bit short on time, but I invite you to read a bit in the docs on the Yubico website. It&#039;s not as simple as you make it sound.</description>
		<content:encoded><![CDATA[<p>etbe: You&#8217;re welcome :) I was asking because I am the maintainer for some of these packages for Fedora, and I know for sure we have pam_yubico, as well as ykpers and libyubikey in Fedora. I&#8217;m considering packaging YubiPAM, but I lack time and development seems a bit slow on it. Oh, I&#8217;m having a hard time with your spam stuff. OpenID refuses to work and keeps calling me a spambot :)</p>
<p>Barak: pam_usb does that, sort of. That project has pretty slow development though. I even think pam_usb got dropped from Fedora for it. The limitation of such a setup would be though, that it would not work &#8211; or at least: not easily &#8211; over a network. Yubikeys are designed to work over the network. Mitm attacks are an issue for a lot of other network authentication mechanisms too. I a bit short on time, but I invite you to read a bit in the docs on the Yubico website. It&#8217;s not as simple as you make it sound.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Barak A. Pearlmutter</title>
		<link>http://etbe.coker.com.au/2010/03/15/yubikey/comment-page-1/#comment-24449</link>
		<dc:creator>Barak A. Pearlmutter</dc:creator>
		<pubDate>Thu, 18 Mar 2010 10:55:27 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=1873#comment-24449</guid>
		<description>So basically this gizmo is a (pseudorandom) one-time pad, and other mechanisms need to be used to ensure that reuse is detected and rejected.  This requires coordination between servers if a single device is to be used with multiple servers.  One compromised server could do a man-in-the-middle attack on login to another server.  Or, a man-in-the-middle attack during login to one server, which kills the connection before that server actually sees the string or bumps the centralized count, could be used by the attacker to either log in to that server later or even to another server.

This sounds a bit vulnerable to me.

(Obviously two-factor authentication, e.g., an additional per-server password, would make such attacks trickier, although perhaps not impossible.  Additional passwords, however, also make the device itself of much less utility, since the password alone provides reasonable security.)

Also, from a practical perspective, couldn&#039;t similar functionality be provided by a USB storage dongle holding some secret information (long one-time pad) together with some program to trickle it out on demand in the right way?</description>
		<content:encoded><![CDATA[<p>So basically this gizmo is a (pseudorandom) one-time pad, and other mechanisms need to be used to ensure that reuse is detected and rejected.  This requires coordination between servers if a single device is to be used with multiple servers.  One compromised server could do a man-in-the-middle attack on login to another server.  Or, a man-in-the-middle attack during login to one server, which kills the connection before that server actually sees the string or bumps the centralized count, could be used by the attacker to either log in to that server later or even to another server.</p>
<p>This sounds a bit vulnerable to me.</p>
<p>(Obviously two-factor authentication, e.g., an additional per-server password, would make such attacks trickier, although perhaps not impossible.  Additional passwords, however, also make the device itself of much less utility, since the password alone provides reasonable security.)</p>
<p>Also, from a practical perspective, couldn&#8217;t similar functionality be provided by a USB storage dongle holding some secret information (long one-time pad) together with some program to trickle it out on demand in the right way?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Fox</title>
		<link>http://etbe.coker.com.au/2010/03/15/yubikey/comment-page-1/#comment-24428</link>
		<dc:creator>Michael Fox</dc:creator>
		<pubDate>Tue, 16 Mar 2010 09:28:35 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=1873#comment-24428</guid>
		<description>My work recently rolled these out, however I am yet to actually test it. I will get around to it, just happy using the one time password setup we have via a bastion type linux host. It works and does what I want. The newer solution was implemented to help those less technical get VPN type access into the corporate environment.</description>
		<content:encoded><![CDATA[<p>My work recently rolled these out, however I am yet to actually test it. I will get around to it, just happy using the one time password setup we have via a bastion type linux host. It works and does what I want. The newer solution was implemented to help those less technical get VPN type access into the corporate environment.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

