<?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: Forgotten password interaction design</title>
	<atom:link href="http://www.jamesmansfield.id.au/forgotten-password-interaction-design/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.jamesmansfield.id.au/forgotten-password-interaction-design/</link>
	<description>UX designer - Melbourne Australia</description>
	<lastBuildDate>Sat, 13 Aug 2011 09:59:00 +1000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.4</generator>
	<item>
		<title>By: Ernie Bello</title>
		<link>http://www.jamesmansfield.id.au/forgotten-password-interaction-design/comment-page-1/#comment-5807</link>
		<dc:creator>Ernie Bello</dc:creator>
		<pubDate>Tue, 28 Jul 2009 16:29:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.jamesmansfield.id.au/?p=343#comment-5807</guid>
		<description>I will also heavily recommend against option 1, as not only will the email be insecure, but the database itself will be as well. In the unlikely -- but very real -- scenario that a web site&#039;s database is hacked, the hacker will also have access to everyone&#039;s password in plain text.

As for the other options, I vote for #3 as well for usability.</description>
		<content:encoded><![CDATA[<p>I will also heavily recommend against option 1, as not only will the email be insecure, but the database itself will be as well. In the unlikely &#8212; but very real &#8212; scenario that a web site&#8217;s database is hacked, the hacker will also have access to everyone&#8217;s password in plain text.</p>
<p>As for the other options, I vote for #3 as well for usability.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeremy</title>
		<link>http://www.jamesmansfield.id.au/forgotten-password-interaction-design/comment-page-1/#comment-5806</link>
		<dc:creator>Jeremy</dc:creator>
		<pubDate>Tue, 28 Jul 2009 00:14:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.jamesmansfield.id.au/?p=343#comment-5806</guid>
		<description>Hi James,

My preference is definitely for the third option. It means I can easily re-set the password (just by clicking on a link), without it being sent to me in plain text.

You&#039;re right about the password encryption (or hashing), but this only precludes option 1. For option 2, the password is generated and sent, then only the hash of the password is stored.

With regards to the email being intercepted, option 1 creates a much larger window of opportunity for an attacker: if someone intercepts that email, they are able to log into my account at any time in the future (or until I change my password). Also, I may have no idea that my password has been taken.

For options 2 and 3, the attacker needs to be the first to see (or act on) the password reset email: once I&#039;ve received it and set a new password, the contents of the email are useless to anyone else. If someone has intercepted the email and beat me to the &#039;change password&#039; stage, then I can tell that this has happened (because the new password or link to click on is now invalid).

I see option 3 as a more usable version of option 2: rather than having to click on a URL to get to your site, then cut &amp; paste the new password, it&#039;s (effectively) encoded on the URL I click on. From there on, both cases can be identical.

Cheers,

Jeremy</description>
		<content:encoded><![CDATA[<p>Hi James,</p>
<p>My preference is definitely for the third option. It means I can easily re-set the password (just by clicking on a link), without it being sent to me in plain text.</p>
<p>You&#8217;re right about the password encryption (or hashing), but this only precludes option 1. For option 2, the password is generated and sent, then only the hash of the password is stored.</p>
<p>With regards to the email being intercepted, option 1 creates a much larger window of opportunity for an attacker: if someone intercepts that email, they are able to log into my account at any time in the future (or until I change my password). Also, I may have no idea that my password has been taken.</p>
<p>For options 2 and 3, the attacker needs to be the first to see (or act on) the password reset email: once I&#8217;ve received it and set a new password, the contents of the email are useless to anyone else. If someone has intercepted the email and beat me to the &#8216;change password&#8217; stage, then I can tell that this has happened (because the new password or link to click on is now invalid).</p>
<p>I see option 3 as a more usable version of option 2: rather than having to click on a URL to get to your site, then cut &amp; paste the new password, it&#8217;s (effectively) encoded on the URL I click on. From there on, both cases can be identical.</p>
<p>Cheers,</p>
<p>Jeremy</p>
]]></content:encoded>
	</item>
</channel>
</rss>

