<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>

<channel>
	<title>Director’s Blog &#187; random</title>
	<atom:link href="http://ls.berkeley.edu/blogs/lscr/category/random/feed/" rel="self" type="application/rss+xml" />
	<link>http://ls.berkeley.edu/blogs/lscr</link>
	<description>Tom Holub\'s thoughts on computing in Letters and Science at UC Berkeley</description>
	<pubDate>Fri, 29 Aug 2008 00:46:39 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
	<language>en</language>
			<item>
		<title>The password is&#8230;&#8221;Archaic&#8221;</title>
		<link>http://ls.berkeley.edu/blogs/lscr/2008/08/11/the-password-isarchaic/</link>
		<comments>http://ls.berkeley.edu/blogs/lscr/2008/08/11/the-password-isarchaic/#comments</comments>
		<pubDate>Mon, 11 Aug 2008 19:30:34 +0000</pubDate>
		<dc:creator>Tom Holub</dc:creator>
		
		<category><![CDATA[random]]></category>

		<guid isPermaLink="false">http://ls.berkeley.edu/blogs/lscr/?p=28</guid>
		<description><![CDATA[A customer forwarded this article from the New York Times, on new authentication mechanisms. The author is cheerleading a bit for &#8220;information cards&#8221; which would act a little like your ATM card; the idea would be that each computer would have a reader where you would insert your card and type in a PIN; after [...]]]></description>
			<content:encoded><![CDATA[<p>A customer forwarded <a href="http://www.nytimes.com/2008/08/10/technology/10digi.html?ex=1219118400&amp;en=7ef56eeaeebf3e5e&amp;ei=5070&amp;emc=eta1">this article from the New York Times</a>, on new authentication mechanisms. The author is cheerleading a bit for &#8220;information cards&#8221; which would act a little like your ATM card; the idea would be that each computer would have a reader where you would insert your card and type in a PIN; after you&#8217;d done that, you&#8217;d have access to all of your sites.</p>
<p>Authentication can have three factors: something you <strong>are</strong> (fingerprint, retinal scan), something you <strong>have</strong> (your ATM card or these information cards), or something you <strong>know</strong> (your password or PIN).  Security experts recommend two-factor authentication for important stuff; you use two-factor authentication when you go to the bank, insert your card and use your PIN.  Two-factor authentication means that the password can be a lot simpler, because one of the other factors is acting as a second check.</p>
<p>However, two-factor authentication is not foolproof, either; there have been sophisticated ATM scams where thieves installed a magnetic stripe reader over the normal slot, with a video camera to record the user&#8217;s PIN as they type it.  One of the things about information cards is that you may have to use them in untrusted environments; if you&#8217;re traveling and want to check your email, nothing will protect you from the hacked machine at the internet cafe where you put in your card.</p>
<p>On campus, IST is developing what they&#8217;re calling &#8220;<a href="https://kb.berkeley.edu/jivekb/entry.jspa?externalID=2565">second level authentication</a>&#8221; which can be used for security-sensitive web-based applications.  This would augment the security of your CalNet ID; for a sensitive application like HRMS, you would log in with your CalNet ID, but then also input a PIN using an on-screen keypad.  This does not qualify as two-factor authentication, because both authentication tokens are &#8220;things you know,&#8221; but it should make those applications somewhat safer.</p>
<p>There is also a significant effort underway on campus and at UCOP to set up an &#8220;identity management&#8221; (IdM) system.  IdM attempts to combine authentication (verifying who the person is) with authorization (verifying what the person should have the rights to access).  Right now CalNet is basically an authentication system; each application which uses CalNet ID must maintain their own list of which CalNet IDs are allowed to access the application.  IdM would provide a central place to store information about each user&#8217;s access rights, and also provide a way (through &#8220;federated identity management&#8221;) to communicate authorization to external entities, like UCOP or a third-party vendor.  UC Davis recently did a pilot to see if GMail could provide email for students; in the pilot, students were able to use the UC Davis equivalent of a CalNet ID to log in to their UC Davis GMail account.  Federated IdM has come a long way in the last year or two (mostly through the <a href="http://shibboleth.internet2.edu/">Shibboleth</a> project), and I expect we&#8217;ll start to see many more of these kinds of arrangements.</p>
]]></content:encoded>
			<wfw:commentRss>http://ls.berkeley.edu/blogs/lscr/2008/08/11/the-password-isarchaic/feed/</wfw:commentRss>
		</item>
		<item>
		<title>CalAgenda DST issue returns</title>
		<link>http://ls.berkeley.edu/blogs/lscr/2007/10/11/calagenda-dst-issue-returns/</link>
		<comments>http://ls.berkeley.edu/blogs/lscr/2007/10/11/calagenda-dst-issue-returns/#comments</comments>
		<pubDate>Thu, 11 Oct 2007 17:43:44 +0000</pubDate>
		<dc:creator>Tom Holub</dc:creator>
		
		<category><![CDATA[random]]></category>

		<guid isPermaLink="false">http://ls.berkeley.edu/blogs/lscr/2007/10/11/calagenda-dst-issue-returns/</guid>
		<description><![CDATA[Mary Wielski wrote an article this spring on Daylight Saving Time issues within CalAgenda.  The issue mentioned in that article is coming back this month; because of the change to the dates of Daylight Saving Time, any repeating meetings which were created before December 29, 2006 are off by one hour in CalAgenda, for meetings [...]]]></description>
			<content:encoded><![CDATA[<p>Mary Wielski wrote an article this spring on <a href="http://ls.berkeley.edu/lscr/news/2007-02-15-DST-bug">Daylight Saving Time issues within CalAgenda</a>.  The issue mentioned in that article is coming back this month; because of the change to the dates of Daylight Saving Time, any repeating meetings which were created before December 29, 2006 are off by one hour in CalAgenda, for meetings scheduled between October 28 and November 4.</p>
<p>There is no way to automatically fix this issue, because the CalAgenda server doesn&#8217;t know what time period you originally intended to schedule the meeting for.  So, make sure to check any standing meetings that have been in place since 2006 to see that the times are correct for this time frame.  You may also want to look forward to 2008 and 2009 and check the same March and October time frames for accuracy.</p>
]]></content:encoded>
			<wfw:commentRss>http://ls.berkeley.edu/blogs/lscr/2007/10/11/calagenda-dst-issue-returns/feed/</wfw:commentRss>
		</item>
	</channel>
</rss>
