<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	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>MicroExperience &#187; Security</title>
	<atom:link href="http://microexperience.com/category/security/feed/" rel="self" type="application/rss+xml" />
	<link>http://microexperience.com</link>
	<description>A look at how small things make a big difference in the user experience</description>
	<lastBuildDate>Wed, 23 May 2012 23:09:50 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
<cloud domain='microexperience.com' port='80' path='/?rsscloud=notify' registerProcedure='' protocol='http-post' />
<image>
		<url>http://s2.wp.com/i/buttonw-com.png</url>
		<title>MicroExperience &#187; Security</title>
		<link>http://microexperience.com</link>
	</image>
	<atom:link rel="search" type="application/opensearchdescription+xml" href="http://microexperience.com/osd.xml" title="MicroExperience" />
	<atom:link rel='hub' href='http://microexperience.com/?pushpress=hub'/>
		<item>
		<title>Trading usability for security</title>
		<link>http://microexperience.com/2007/11/21/trading-usability-for-security/</link>
		<comments>http://microexperience.com/2007/11/21/trading-usability-for-security/#comments</comments>
		<pubDate>Wed, 21 Nov 2007 13:36:52 +0000</pubDate>
		<dc:creator>microexperience</dc:creator>
				<category><![CDATA[Security]]></category>
		<category><![CDATA[Usability]]></category>
		<category><![CDATA[User Experience]]></category>

		<guid isPermaLink="false">http://microexperience.com/2007/11/21/trading-usability-for-security/</guid>
		<description><![CDATA[I got a little message from salesforce.com last night. Well, not very little at all. You see, it took them over 700 words to explain how to use the new login process, designed to keep users from having their login information stolen. I&#8217;ve never found them to be very concise in their communication with customers, [...]<img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=microexperience.com&#038;blog=1575733&#038;post=81&#038;subd=microexperience&#038;ref=&#038;feed=1" width="1" height="1" />]]></description>
			<content:encoded><![CDATA[<p>I got a little message from salesforce.com last night. Well, not very little at all. You see, it took them over 700 words to explain how to use the new login process, designed to keep users from having their login information stolen. I&#8217;ve never found them to be very concise in their communication with customers, so the length of the message is nothing new. However, the new login process they describe is rather troubling. With a verification system that is sure to annoy users and administrators alike, salesforce has taken a big step backwards in usability. </p>
<p>The new login process works like this: unless you&#8217;re accessing the service from a trusted IP address (which your account administrator has to update manually), then you&#8217;ll need to go through a verification process every time you want to login from a new computer or a new location. The verification involves clicking a link to send an email to your address on file, opening the email, clicking a link that registers your current IP and browser, and then logging in normally. </p>
<p>There are some major issues here. First, they&#8217;re presumably using a cookie to record which browser has been verified. So if you clear your cookies, you&#8217;ll have to get verified all over again. Second, a lot of people are on dynamic IPs, especially if they often work from remote locations or wireless devices. They will need to do the verification whenever they move to a new location and the IP changes, or possibly even if they just sign off and back on (since some wireless services assign a new IP for every session). A VPN can prevent this hassle, but I&#8217;m guessing many of salesforce&#8217;s SMB customers lack this sort of infrastructure. And what if you don&#8217;t have access to your corporate email account on the same computer, e.g. if you&#8217;re using a shared PC? Sounds like you&#8217;re out of luck. </p>
<p>Ironically, I think the biggest problem is that salesforce is training users to expect these official verification emails all the time. Aren&#8217;t these the same sort of things that potential attackers use to get people to click on and capture their private data? Previously, you could simply say &#8220;Delete any email about salesforce access, since it&#8217;s a scam.&#8221; Now, users have to distinguish between  legitimate verification emails they are expecting, and fraudulent ones. This sounds easy enough. But in practice, people will quickly get accustomed to just clicking on the message, especially if they get the verification requests all the time. This change in user behavior will make tricking the average salesforce user even easier in the future. </p>
<p>In all, this is a bad move for salesforce in terms of usability. And by training users to click on verification emails, it might lead to even more compromised accounts as thieves learn to emulate the email format. I would much prefer to see salesforce implement the multi-factor authentication that banks use, i.e. asking you to answer more security questions right on the login screen if your computer isn&#8217;t recognized. Obviously, salesforce has its reasons for taking this approach, but I suspect it&#8217;s going to cause a lot more harm than good.</p>
<br /><img alt="" border="0" src="http://feeds.wordpress.com/1.0/categories/microexperience.wordpress.com/81/" /> <img alt="" border="0" src="http://feeds.wordpress.com/1.0/tags/microexperience.wordpress.com/81/" /> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/gocomments/microexperience.wordpress.com/81/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/comments/microexperience.wordpress.com/81/" /></a> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/godelicious/microexperience.wordpress.com/81/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/delicious/microexperience.wordpress.com/81/" /></a> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/gofacebook/microexperience.wordpress.com/81/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/facebook/microexperience.wordpress.com/81/" /></a> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/gotwitter/microexperience.wordpress.com/81/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/twitter/microexperience.wordpress.com/81/" /></a> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/gostumble/microexperience.wordpress.com/81/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/stumble/microexperience.wordpress.com/81/" /></a> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/godigg/microexperience.wordpress.com/81/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/digg/microexperience.wordpress.com/81/" /></a> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/goreddit/microexperience.wordpress.com/81/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/reddit/microexperience.wordpress.com/81/" /></a> <img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=microexperience.com&#038;blog=1575733&#038;post=81&#038;subd=microexperience&#038;ref=&#038;feed=1" width="1" height="1" />]]></content:encoded>
			<wfw:commentRss>http://microexperience.com/2007/11/21/trading-usability-for-security/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
	
		<media:content url="http://0.gravatar.com/avatar/ab2b736d9047c4319491e4334347f24c?s=96&#38;d=http%3A%2F%2F0.gravatar.com%2Favatar%2Fad516503a11cd5ca435acc9bb6523536%3Fs%3D96&#38;r=G" medium="image">
			<media:title type="html">microexperience</media:title>
		</media:content>
	</item>
		<item>
		<title>Never email passwords to your users</title>
		<link>http://microexperience.com/2007/08/28/never-email-passwords-to-your-users/</link>
		<comments>http://microexperience.com/2007/08/28/never-email-passwords-to-your-users/#comments</comments>
		<pubDate>Tue, 28 Aug 2007 12:21:32 +0000</pubDate>
		<dc:creator>microexperience</dc:creator>
				<category><![CDATA[Design]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[User Experience]]></category>

		<guid isPermaLink="false">http://microexperience.com/2007/08/28/never-email-passwords-to-your-users/</guid>
		<description><![CDATA[You could write volumes about password and security issues on the web. Some issues are highly complex, while others are common sense like &#8220;don&#8217;t write your password on a sticky note on your monitor&#8221;. In fact, if you&#8217;re trying to create a good password policy for your application, Thomas Baekdal just wrote an excellent article [...]<img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=microexperience.com&#038;blog=1575733&#038;post=12&#038;subd=microexperience&#038;ref=&#038;feed=1" width="1" height="1" />]]></description>
			<content:encoded><![CDATA[<p>You could write volumes about password and security issues on the web.  Some issues are highly complex, while others are common sense like &#8220;don&#8217;t write your password on a sticky note on your monitor&#8221;. In fact, if you&#8217;re trying to create a good password policy for your application, Thomas Baekdal just wrote an excellent article on <a href="http://www.baekdal.com/articles/Usability/password-security-usability/">how to create secure passwords</a> that users can actually remember. But that&#8217;s not what I&#8217;m writing about today.</p>
<p>My request is very simple: Never email users their password.  Why? In most cases, email is an insecure method of communication.  Email can be intercepted. So every time you email a password to your users, there is a chance that the password could be compromised &#8212; along with all of the user&#8217;s data inside your web application.</p>
<p>This behavior isn&#8217;t limited to poorly-made sites.  I have seen everything from airline frequent flyer sites to project management applications send an email with the username and password right after creating an account. Even more sites skimp on the &#8220;Forgot Password&#8221; feature.  Instead of generating a new password, they just email you the existing one &#8212; further exposing the password to prying eyes.</p>
<p>Fixing this problem is straightforward:</p>
<ul>
<li>Never email users their password, either during initial account creation or subsequent password resets.</li>
<li>When a user forgets their password, give them a way to generate a new one.  Make this a temporary password that they have to change after logging in. You can even email this if you want, since it&#8217;s only valid for one-time use.</li>
<li>If you really want users to have a copy of their password so they don&#8217;t keep asking for password resets, let them view their initial password or retrieve it later from a secure form on your site.  Then they can print this out if they like, without compromising the security of the password. Just don&#8217;t email it.</li>
</ul>
<p>As a final note, if the password features in your software are really difficult or impossible to change, at least have the decency to warn people in advance that you&#8217;re going to email them their password.  Then they can decide if they want to use a different password or perhaps think a little bit harder about what their old one was.</p>
<br /><img alt="" border="0" src="http://feeds.wordpress.com/1.0/categories/microexperience.wordpress.com/12/" /> <img alt="" border="0" src="http://feeds.wordpress.com/1.0/tags/microexperience.wordpress.com/12/" /> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/gocomments/microexperience.wordpress.com/12/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/comments/microexperience.wordpress.com/12/" /></a> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/godelicious/microexperience.wordpress.com/12/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/delicious/microexperience.wordpress.com/12/" /></a> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/gofacebook/microexperience.wordpress.com/12/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/facebook/microexperience.wordpress.com/12/" /></a> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/gotwitter/microexperience.wordpress.com/12/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/twitter/microexperience.wordpress.com/12/" /></a> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/gostumble/microexperience.wordpress.com/12/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/stumble/microexperience.wordpress.com/12/" /></a> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/godigg/microexperience.wordpress.com/12/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/digg/microexperience.wordpress.com/12/" /></a> <a rel="nofollow" href="http://feeds.wordpress.com/1.0/goreddit/microexperience.wordpress.com/12/"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/reddit/microexperience.wordpress.com/12/" /></a> <img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=microexperience.com&#038;blog=1575733&#038;post=12&#038;subd=microexperience&#038;ref=&#038;feed=1" width="1" height="1" />]]></content:encoded>
			<wfw:commentRss>http://microexperience.com/2007/08/28/never-email-passwords-to-your-users/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
	
		<media:content url="http://0.gravatar.com/avatar/ab2b736d9047c4319491e4334347f24c?s=96&#38;d=http%3A%2F%2F0.gravatar.com%2Favatar%2Fad516503a11cd5ca435acc9bb6523536%3Fs%3D96&#38;r=G" medium="image">
			<media:title type="html">microexperience</media:title>
		</media:content>
	</item>
	</channel>
</rss>
