The usability of password forms and security policies

Screen Shot 2013-07-12 at 3.31.16 PM

In the modern world, people have a decent amount of information stored online: social networks, e-mail, wiki’s, corporate portals, etc. We sign up for countless applications over the course of year, sometimes just to try, sometimes to indeed use it. Personal information has merged with job-related information. Under these circumstances security of this information is very important. To classify ways of getting access to someone else’s account (applied to client-server technologies that are most common in current web applications), one could use:

  • Server-side vulnerability (system vulnerability)
  • Client-side vulnerability (phishing, keylogging, etc.)
  • Vulnerability on the level of data transmission
  • Password cracking
    • Brute force
    • Dictionary attack
    • Educated guess

The first 3 items have to deal with computer science and that’s what has been researched, analyzed and improved. However, as these elements improve, so does the realization that it doesn’t only affect security. Let’s look at a couple of examples.

In July 2009, Twitter was at risk of having important security-sensitive information (financial projections, board meeting transcripts, phone call logs, etc.) being leaked to the public or sold to interested parties. A hacker was able to gain access to over three hundred documents because of over-looked human error. The sequence was as follows:

  • The intruder was able to “restore password” for the private Gmail account of one of the employees, re-creating expired account which was included, as the alternative mailbox. Because that Hotmail box had the same name as the Gmail account.
  • The hacker was able to reset password back to the normal state, finding multiple instances of the same password used for different online services.
  • The very same password was used for a Twitter corporate mailbox of the same employee. So the hacker gained access to that mailbox too.
  • Having useful information from one employee’s mailbox, the hacker applied the same method to gain access to other employees’ mailboxes as well as various services, such as iTunes, AT&T, MobileMe, Amazon, etc.

Another example is Gary McKinnon, who made educated guesses on passwords of computer systems belonging to U.S. government networks.

We are not going to address issues of cloud storage, but rather show why text-based passwords are insecure:

  • Users typically set weak, mainly lowercase-only passwords whenever they can.
  • Users almost never reset passwords, unless they are forced to.
  • Users typically write down passwords when they can’t use the same password after reset or restore.
  • Users are often afraid to forget passwords because they find restore process “painful.”

The reasons for this are limitations of short term memory, differences in rehearsal span of different individuals and just plain stubbornness. The following controversy comes into play: passwords should be secure enough for the system and easy enough for user to remember and use. On one hand, security passwords and forms for password should be strict and restrict “the lazy user.” On the other hand there should be some usability that helps users.

But how do we determine, where usability becomes clear hints for any given hacker? In the above example, Google shows secondary email address as this: ******@h******.com which helped the hacker to determine that the secondary mailbox is at Hotmail. The issues of password policies are addressed in Inglesant’s and Sasse research work [PDF]. They conclude that rather than concentrating on password length and frequency of use, policies should help the user set strong passwords appropriately in the specific context of use. Latter is also important, as most passwords appear “stared” or “bulleted,” not only when one sets them, but also as typing in. Nielsen suggests removing password masking all together leaving a choice for the user to hide if he or she needs to. In addition, validation of the form should be usable, the most appropriate way – inline validation, where fields are being validated as you type. An example of a “restore password” form with low usability and very high standards can be observed at To further help users and add an additional layer of security, cognitional questions were utilized, where questions such as “What’s your pet’s name?” are being asked. However, if one uses true answers then a hacker could potentially find answers either using Google or Facebook. Though, If one uses fake answers, there may be no way to restore it if you forget it. So, choose your passwords thoughtfully!