<?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/"
xmlns:series="http://organizeseries.com/"
> <channel><title>Comments on: Strengthen User Authentication and Preserve User Experience</title> <atom:link href="http://www.sitepoint.com/strengthen-user-authentication-and-preserve-user-experience/feed/" rel="self" type="application/rss+xml" /><link>http://www.sitepoint.com/strengthen-user-authentication-and-preserve-user-experience/</link> <description>Learn CSS &#124; HTML5 &#124; JavaScript &#124; Wordpress &#124; Tutorials-Web Development &#124; Reference &#124; Books and More</description> <lastBuildDate>Mon, 13 May 2013 20:55:10 +0000</lastBuildDate> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <generator>http://wordpress.org/?v=3.5.1</generator> <item><title>By: Dave</title><link>http://www.sitepoint.com/strengthen-user-authentication-and-preserve-user-experience/#comment-1086382</link> <dc:creator>Dave</dc:creator> <pubDate>Fri, 10 May 2013 09:02:43 +0000</pubDate> <guid
isPermaLink="false">http://www.sitepoint.com/?p=66050#comment-1086382</guid> <description><![CDATA[I agree with Anthony, especially on the point about telling the user whether they got their username or password wrong. Websites that force you to guess what information you got wrong are very annoying.]]></description> <content:encoded><![CDATA[<p>I agree with Anthony, especially on the point about telling the user whether they got their username or password wrong. Websites that force you to guess what information you got wrong are very annoying.</p> ]]></content:encoded> </item> <item><title>By: Anthony</title><link>http://www.sitepoint.com/strengthen-user-authentication-and-preserve-user-experience/#comment-1086102</link> <dc:creator>Anthony</dc:creator> <pubDate>Tue, 07 May 2013 21:58:17 +0000</pubDate> <guid
isPermaLink="false">http://www.sitepoint.com/?p=66050#comment-1086102</guid> <description><![CDATA[Default reference for these questions: http://codahale.com/how-to-safely-store-a-password/]]></description> <content:encoded><![CDATA[<p>Default reference for these questions: <a
href="http://codahale.com/how-to-safely-store-a-password/" rel="nofollow">http://codahale.com/how-to-safely-store-a-password/</a></p> ]]></content:encoded> </item> <item><title>By: Jeff Safire</title><link>http://www.sitepoint.com/strengthen-user-authentication-and-preserve-user-experience/#comment-1086069</link> <dc:creator>Jeff Safire</dc:creator> <pubDate>Tue, 07 May 2013 16:05:50 +0000</pubDate> <guid
isPermaLink="false">http://www.sitepoint.com/?p=66050#comment-1086069</guid> <description><![CDATA[Thanks for this valuable info. But, why is MD5 not secure for hashing passwords?]]></description> <content:encoded><![CDATA[<p>Thanks for this valuable info. But, why is MD5 not secure for hashing passwords?</p> ]]></content:encoded> </item> <item><title>By: Graham Bradley</title><link>http://www.sitepoint.com/strengthen-user-authentication-and-preserve-user-experience/#comment-1086041</link> <dc:creator>Graham Bradley</dc:creator> <pubDate>Tue, 07 May 2013 11:27:15 +0000</pubDate> <guid
isPermaLink="false">http://www.sitepoint.com/?p=66050#comment-1086041</guid> <description><![CDATA[&quot;Require a strong username that includes a numeric character.&quot;
How does this preserve the user experience? Adding hints for strong credentials is great, but restrictions like this, which appear arbitrary to the user, caused a large number of our users to either forget their username or abandom signup completely.]]></description> <content:encoded><![CDATA[<p>&#8220;Require a strong username that includes a numeric character.&#8221;</p><p>How does this preserve the user experience? Adding hints for strong credentials is great, but restrictions like this, which appear arbitrary to the user, caused a large number of our users to either forget their username or abandom signup completely.</p> ]]></content:encoded> </item> <item><title>By: Anthony</title><link>http://www.sitepoint.com/strengthen-user-authentication-and-preserve-user-experience/#comment-1086034</link> <dc:creator>Anthony</dc:creator> <pubDate>Tue, 07 May 2013 10:49:23 +0000</pubDate> <guid
isPermaLink="false">http://www.sitepoint.com/?p=66050#comment-1086034</guid> <description><![CDATA[I find that some of the minimum standards you quote are actually barriers for users on most sites:
&quot;Enforce a dictionary check to ensure that users cannot choose common words for their password.&quot;
This forces a user to select a difficult-to-remember password. If your site is one that they don&#039;t use regularly (ie isn&#039;t Facebook, or Twitter) then they&#039;ll probably completely forget their password, forcing them down an often painful password-reset process. Surely only recommended on busy sites, or those with highly sensitive information (such as ebanking)
&quot;Require a strong username that includes a numeric character. Often the username is the easiest portion of the login credentials for a hacker to guess. Do not use the user’s email address as their username.&quot;
As above, if your site isn&#039;t one that the user logs into regularly, the chances of them remembering a username instead of just using their email address is slim. I have numerous sites that I need to log into occasionally (mobile phone operator, satellite TV, gas and electric provider) and some force usernames on me, others email addresses. The username ones I always struggle to log into because they have these different definitions of what an acceptable username is, or what was available at the time. Usernames are great for sites such as discussion forums, where you need an avatar and to protect your email address from the prying public, but otherwise I prefer to use email addresses as usernames. Of course, on forums, your usename is easy to see, so it makes more sense there to log a user in with an email address that is not being displayed hundreds of times around the site. As for forcing numbers into usernames; this creates an additional world of pain and will put most users off of signing up. I&#039;d much rather use a simple username (if an email address is unavoidable) and consider an additional step, such as confirming a couple of letters from a pre-determined secret word if required
&quot;Limit the number of failed login attempts to three and temporarily suspend account access unless the user can authenticate through other means.&quot;
This I DO completely agree with, and in some cases (PCI environments, for example) only an administrator should be able to reactivate once suspended. However, this only addresses front-end security and not the back-end data that has been compromised in the Sony/LinkedIn examples
&quot;If the login fails, don’t identify which portion of the credentials was incorrect. Stating that the ‘password is incorrect’ or the ‘username doesn’t exist’ enables hackers to harvest account information. A general statement such as “Incorrect login, please try again” helps prevent account harvesting.&quot;
I&#039;d rather aid account harvesting than provide vague error messages to the user. Usability always recommends that you highlight where you&#039;ve gone wrong. I could be trying loads of different passwords, trying to log in, only to lock someone else&#039;s account because I didn&#039;t realise that my username on this site was actually &quot;anthony2&quot; and not &quot;anthony1&quot;, because someone decided that letting me log in with my email address as a username was a bad idea. In fact, I&#039;ve recently given up with a website because I needed to reset a password and it asks for my email address and username to reset. I only know the email address associated with it, so now I can&#039;t get in and spend the credit that I already have. Too complicated! The only exception would be where you may need to use sensitive data to log in, such as a bank card number. I wouldn&#039;t want to confirm that this was correct or not as part of the process of signing in
&quot;Use SSL to create an encrypted link between your server and the user’s web browser during account enrolment, the login process and the password reset process.&quot;
Agreed. Can&#039;t imagine many would disagree. SSL isn&#039;t always an option to everyone though, especially not with a certificate signed by a public CA, such as Verisign
&quot;Provide users with advice on how to choose a strong username and password. Research shows that users do choose better passwords when given advice on how to do so. One option is to have a password strength meter built into the page.&quot;
Again, agree. But advise rather than force. If a user chooses to go against your advice then they need to accept the consequences. However, you may want to force higher restrictions on users with elevated privileges. Also, bear in mind that the more rigid your password policy, the easier it is to guess passwords. If you force a capital and a number, you can be pretty sure that instead of &quot;password&quot; being the most common password, that it will just become &quot;Password1&quot; or &quot;Passw0rd&quot;. Add a symbol and it might just become &quot;Passw0rd!&quot;. These patterns are easily predicted for most users. Allowing the password to be anything at all can sometimes make it even harder to crack
&quot;Hash user passwords using bcrypt, scrypt, or other hash algorithms specifically designed to store passwords. Do not use SHA1, MD5 or other algorithms that were not designed for hashing passwords, as they are not secure.&quot;
Again, I completely agree. Personally I use bcrypt in PHP wherever possible. I especially like that we can increase rounds as computing power increases to make it more difficult for anyone to calculate passwords should our database be compromised. In PHP there is also no choice but to salt bcrypt&#039;d passwords
&quot;Use Salt. Use a unique salt for each user account/password and store that salt with the password. An additional layer of system wide salt that is not stored with the password can also add extra strength if the database is stolen because it is not stored with the passwords but is known to you.&quot;
Also agree
There is always a trade-off between making the most secure system, and making a usable system. For MOST sites, it&#039;s more important to make them usable and therefore much of these recommendations will go out of the window. It&#039;s common sense and that would explain why CU find that most sites don&#039;t meet these minimum recommendations. They&#039;re theoretically great, but in practice just add too many barriers, and in this world of high-competition online, the more challenges you throw in front of the user, the less likely they are to ever sign up, never mind come back again. In fact, some of the best signup forms I&#039;ve ever seen ask only for your email address, and you&#039;re signed up. A password is sent to you and you can change it, of course, but no barriers. No complicated signup. And if you want to reset your account? Just give them your email address again. Perfectly acceptable for most sites.]]></description> <content:encoded><![CDATA[<p>I find that some of the minimum standards you quote are actually barriers for users on most sites:</p><p>&#8220;Enforce a dictionary check to ensure that users cannot choose common words for their password.&#8221;<br
/> This forces a user to select a difficult-to-remember password. If your site is one that they don&#8217;t use regularly (ie isn&#8217;t Facebook, or Twitter) then they&#8217;ll probably completely forget their password, forcing them down an often painful password-reset process. Surely only recommended on busy sites, or those with highly sensitive information (such as ebanking)</p><p>&#8220;Require a strong username that includes a numeric character. Often the username is the easiest portion of the login credentials for a hacker to guess. Do not use the user’s email address as their username.&#8221;<br
/> As above, if your site isn&#8217;t one that the user logs into regularly, the chances of them remembering a username instead of just using their email address is slim. I have numerous sites that I need to log into occasionally (mobile phone operator, satellite TV, gas and electric provider) and some force usernames on me, others email addresses. The username ones I always struggle to log into because they have these different definitions of what an acceptable username is, or what was available at the time. Usernames are great for sites such as discussion forums, where you need an avatar and to protect your email address from the prying public, but otherwise I prefer to use email addresses as usernames. Of course, on forums, your usename is easy to see, so it makes more sense there to log a user in with an email address that is not being displayed hundreds of times around the site. As for forcing numbers into usernames; this creates an additional world of pain and will put most users off of signing up. I&#8217;d much rather use a simple username (if an email address is unavoidable) and consider an additional step, such as confirming a couple of letters from a pre-determined secret word if required</p><p>&#8220;Limit the number of failed login attempts to three and temporarily suspend account access unless the user can authenticate through other means.&#8221;<br
/> This I DO completely agree with, and in some cases (PCI environments, for example) only an administrator should be able to reactivate once suspended. However, this only addresses front-end security and not the back-end data that has been compromised in the Sony/LinkedIn examples</p><p>&#8220;If the login fails, don’t identify which portion of the credentials was incorrect. Stating that the ‘password is incorrect’ or the ‘username doesn’t exist’ enables hackers to harvest account information. A general statement such as “Incorrect login, please try again” helps prevent account harvesting.&#8221;<br
/> I&#8217;d rather aid account harvesting than provide vague error messages to the user. Usability always recommends that you highlight where you&#8217;ve gone wrong. I could be trying loads of different passwords, trying to log in, only to lock someone else&#8217;s account because I didn&#8217;t realise that my username on this site was actually &#8220;anthony2&#8243; and not &#8220;anthony1&#8243;, because someone decided that letting me log in with my email address as a username was a bad idea. In fact, I&#8217;ve recently given up with a website because I needed to reset a password and it asks for my email address and username to reset. I only know the email address associated with it, so now I can&#8217;t get in and spend the credit that I already have. Too complicated! The only exception would be where you may need to use sensitive data to log in, such as a bank card number. I wouldn&#8217;t want to confirm that this was correct or not as part of the process of signing in</p><p>&#8220;Use SSL to create an encrypted link between your server and the user’s web browser during account enrolment, the login process and the password reset process.&#8221;<br
/> Agreed. Can&#8217;t imagine many would disagree. SSL isn&#8217;t always an option to everyone though, especially not with a certificate signed by a public CA, such as Verisign</p><p>&#8220;Provide users with advice on how to choose a strong username and password. Research shows that users do choose better passwords when given advice on how to do so. One option is to have a password strength meter built into the page.&#8221;<br
/> Again, agree. But advise rather than force. If a user chooses to go against your advice then they need to accept the consequences. However, you may want to force higher restrictions on users with elevated privileges. Also, bear in mind that the more rigid your password policy, the easier it is to guess passwords. If you force a capital and a number, you can be pretty sure that instead of &#8220;password&#8221; being the most common password, that it will just become &#8220;Password1&#8243; or &#8220;Passw0rd&#8221;. Add a symbol and it might just become &#8220;Passw0rd!&#8221;. These patterns are easily predicted for most users. Allowing the password to be anything at all can sometimes make it even harder to crack</p><p>&#8220;Hash user passwords using bcrypt, scrypt, or other hash algorithms specifically designed to store passwords. Do not use SHA1, MD5 or other algorithms that were not designed for hashing passwords, as they are not secure.&#8221;<br
/> Again, I completely agree. Personally I use bcrypt in PHP wherever possible. I especially like that we can increase rounds as computing power increases to make it more difficult for anyone to calculate passwords should our database be compromised. In PHP there is also no choice but to salt bcrypt&#8217;d passwords</p><p>&#8220;Use Salt. Use a unique salt for each user account/password and store that salt with the password. An additional layer of system wide salt that is not stored with the password can also add extra strength if the database is stolen because it is not stored with the passwords but is known to you.&#8221;<br
/> Also agree</p><p>There is always a trade-off between making the most secure system, and making a usable system. For MOST sites, it&#8217;s more important to make them usable and therefore much of these recommendations will go out of the window. It&#8217;s common sense and that would explain why CU find that most sites don&#8217;t meet these minimum recommendations. They&#8217;re theoretically great, but in practice just add too many barriers, and in this world of high-competition online, the more challenges you throw in front of the user, the less likely they are to ever sign up, never mind come back again. In fact, some of the best signup forms I&#8217;ve ever seen ask only for your email address, and you&#8217;re signed up. A password is sent to you and you can change it, of course, but no barriers. No complicated signup. And if you want to reset your account? Just give them your email address again. Perfectly acceptable for most sites.</p> ]]></content:encoded> </item> </channel> </rss>
<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using memcached
Database Caching 36/44 queries in 0.035 seconds using memcached
Object Caching 478/482 objects using memcached

Served from: www.sitepoint.com @ 2013-05-13 14:31:58 --