With Governor Sarah Palin’s very public web-email security breach this week, there are dozens of blogs and websites pointing out how common password reset schemes are broken and debating how to improve the security of password reset tools.
Of course, password reset is just one part of the login experience which could use some improvement. There are a variety of ways to set up a web login system. A survey of many of the leading social networking and web services reveals some best practices and a number of less than satisfactory solutions. The choice of approach to a login ID determines how users must act to recover usernames and passwords and what kinds of verification must be provided.
Many sites use a member’s email address as their user ID. The email address functions as identification and the password as authentication. The other option which seems to have dropped out of fashion is to allow the member to choose a username as their user ID. Each of the approaches has supporters and detractors, many of the positions are well articulated in an old IXDA thread titled: email address as username.
The most compelling argument in favor of usernames is that there less constraints than an email address. This strength actually becomes a weakness because without constraints users can create usernames they will have trouble remembering. Usernames do not scale well. The simple, clear and straightforward ones are taken quickly late comers must choose variants like edward345 or some other arbitrary distinction from all of the other “edwards”.
Email addresses are easier to remember than usernames. This means people are less likely to abandon the site altogether or sign up with a new username, creating unused ghost accounts. People must strive to create unique usernames. Creating a unique username gets harder as more and more people are added to the system. All of the straightforward names like Scott are quickly taken and new users have to settle for creating something like Scott1989; arbitrary, concocted, forgettable. Email addresses are naturally unique (only one person at a time has control of the account).
Some argue that because email addresses are used everyday as a means of addressing communication, their lack of secrecy makes them less secure than arbitrary usernames. Robert Barlow-Busch responded with. “The purpose of the userID is simply to identify, not to authenticate.” He is right, passwords provide the security, the user ID the identification. Often the email address is used both for identification and communication. This blurring of roles leads to some of the problems with using email addresses as identification.
Another argument against using email addresses as user id made by Jakob Nelson (8 years ago) is that some users get confused when asked to use their email address to login to an online system. He states that they assume they need to provide their email password, not the system password. While this may remain an issue for fringe users, I think we can safely assume that people are familiar enough with setting up multiple accounts that all use their email address as identification that it’s a not issue in 2008.
As the web has grown up the the likelihood that people have more than one email address has increased. It is not uncommon for people to have a personal email address, a spam email address, a work email address and webmail address. The existence of multiple email addresses can make it harder for people to remember which one they used for a given account. Another possibility is that a user supplies an entirely fake email address, but this is so extreme that it’s hardly worth trying to design a system for.
Christina Wodtke relayed a story in criticism of email address as login. “Network Solutions is holding my domain name hostage, because I am no longer at the email they have on record, and they want me to fax a passport and a bill and other stuff to prove I’m me.” This isn’t a problem of identity it is a problem of using the email address as validation. A system needs to allow people who no longer have control of an email address an alternative way to validate themselves.
Email addresses do have an Achilles-heel. People change email addresses as time passes. Their Internet provider may change, they may get a new job, or switch to a less evil web-mail provider. It is not common, but employees do inherit email addresses previously assigned to other people, particularly in smaller companies where email@example.com is the standard. Peter Trudelle relates “Most of the email addresses I’ve had over the years are no longer under my control; any/all of them could have been re-used by others.””
Facebook requires users to sign up with an email address, their name, age and a password. The email address is initially used to validate the new account. Users are allowed change and to attach multiple email addresses to their accounts. Working email accounts are required to validate networks like schools and employers. Forget your password? Just enter in your email address and a password reset link will be sent to your email address. A nice bonus is that you can use any email address attached to your account.
In the event that a user only attaches one email address to their account and forgets what email address they used Facebook provides a quick two-step process toward recovery. After following a couple of links to the right help page you are asked to “click here” to solve your issue. Not a great call to action, but it works, bringing up a screen where the user is prompted to enter in identifying information like their name, DOB, possible email addresses which are linked to the account and what networks they are in. It’s clean quick and seems relatively difficult to game.
The only difficult part of Facebook is that they allow members to add work email addresses, creating a situation where they can “squat” on the email address once they move on to another job. If someone with the email address of firstname.lastname@example.org stops working at CompanyX. And a new guy named James is hired at CompanyX and given the email address email@example.com he will not be allowed to sign up for a facebook account with the email address firstname.lastname@example.org. The old James will need to manually delete the address from his account before the new James can add it. This is clearly not going to work well for the new James.
LinkedIn also allows users to change and add multiple email addresses to their accounts. Like Facebook they don’t allow more than one user in the system to claim and email address. Email addresses are attached to an account by validating it while it is under the user’s control. Once the email address is attached to the account it must be manually removed before someone else can sign up or attach it to their account.
If a user forgets their password Linkedin allows them to request an password reset link email to any of the accounts associated with their account. If the user has only one email address on record, and can no longer access to that email address, they are forced to use a form to email customer service. It is unclear what they do to validate a user and reset the password.
If a users forgets what email account they used to sign up? They must abandon the account, there are no means of recovery. The only option is to create a new account. The investment in writing recommendations, getting recommendations, making connections and keeping an up-to-date profile is “lost”. The user can no longer maintain, change or access it.
Yahoo! Forces people to use a Yahoo! email address as the login ID for Flickr. As they can’t use any other email address this essentially works as a username. It can’t be changed, though the account can be moved to another Yahoo! account, providing at least a clumsy and database intensive way to change usernames (a second email address can be added to the account for communications purposes).
If a user forgets their Yahoo ID, they are asked to provide their alternate email address attached to the account. If a user can’t remember or guess the alternate email address there is no recourse, but to keep guessing. If the email works, Yahoo asks for validating information such as birthdate, coutry, and postal code. If they can match these to an account they send an email with the login to the secondary email account.
Flickr also introduces two other identity concepts; the screen name (what people will see when next to users comments) and a custom Flickr web address. Screen names are easy to change. The web address is unique and can only be chosen once. What is good about this is that they don’t force people to have web addresses that are the same as their yahoo email address.
What is bad is that once the web address is chosen it becomes hardwired into the system. There are ample warnings about this at the time of creation, but it doesn’t help when two years later name that was cool and ironic in school isn’t so cool, and leans sophomoric. It also reintroduces the username problem. The early adopters will all have the simple straightforward names. The masses who come later will be forced to use more esoteric names or add in arbitrary characters to produce a unique URL.
Amazon allows users to change their email address which also acts as their login. It’s the standard email the password reset link in the event that the password is forgotten.
Users who forget their username hit a brick wall. There is no way to retrieve an account login. Amazon states it clearly, and goes so far as to provide a link to create an entirely new account; virtually encouraging users with a poor memory to abandon what might be years of purchase preferences, credit card information, ratings and community.
Gmail (Google Mail)
For obvious reasons you can’t change your email address, your username is your email address and that’s the point of the service. Want to change your username? Create a new account.
Google can’t rely on the standard email recovery of the forgotten password, because the email would be sent to Gmail, which is the account they can’t access. Instead they ask users to submit their username. After passing the bot protection screen users are asked to supply the answer to the validation question they wrote for themselves when they created the account. The question could be anything, it is open to the user to create a question and answer which are meaningful to themselves.
This is a great example of giving the user the power to create a validation which because it is uniquely theirs offers a better chance they will pass. In the unlikely event that a user can’t answer their own question Google provides a second way. Users can change their password by sending a validation email to a secondary email address on file. If the secondary address is one which the user no longer has access to Google provides a third way to get help. Users must submit a help ticket similar to the form used by Facebook. Google’s form asks more precise questions from the user such as what was the last successful login date, last password remembered, when the account was created, and what other Google products are used with the account.
Google relies on a secondary email address for recovery of the username. They do suggest that if the user has a copy of the account creation email they can retrieve their username from the message, but I imagine this is a distant chance for most users.
Bank of America
Bank of America and a number of other online banks distribute the login process across a number of pages. The user must enter their Online ID (username). (Once a user chooses a login ID it is impossible to change it.) Instead of a password the site asks for the physical location (what state is it in?) of the account. The user has the option to save their username on the computer they are using, meaning the next time they come to the site they will only need to enter in their Passcode (password). They use a SiteKey, a visual identification of an image on the next screen as an anti-phishing measure. (The logic being that a fake site set up by phishers wouldn’t know what photo you had previously selected as your SiteKey.) If the BofA Web site doesn’t recognize the computer you’re using (via cookies), you will also be asked an additional question, strengthening the security beyond simple password-strength.
If a user needs to reset their password they first must identify the state they bank in. They then need to enter in their username. The third step is to identify what kind of account the user has with BofA. If they correctly identify the account they can enter in a new password on the final screen. Before the system will accept the new password the user must supply additional verification in the form of the last four digits of their social, the credit card or bank account number, the security code from the back of the card, the experation date and the zip code of the billing address. It’s alot of information but it’s a bank account. The user’s investment is literally their money.
So what would the ultimate login system provide?
Creating the account
When a new user signs up the system should generate a masked unique system ID. With the static sytem ID, all of the variables attached to it can be changed without affecting the ability of the system to track the user. Some users genuinely prefer to use a username, others prefer email. The system should allow users to create a username or use an email address as their login ID.
Allow users to add as many email addresses as they like to their account. It gives them flexibility in communications and verification.
Require the appropriate level of validation for the user’s investment. They system should respect that some users will use it rarely and when they do won’t invest much time or resources in their account. They may use it just to download trial software, and ignore the social networking, forums, ratings, and financial transactions. This user’s investment is low. If they can’t access their account it will be a minor inconvenience, and they will probably just create a new one. Abandoning the account doesn’t hurt. Users like this should not be required to provide alternate email addresses, or validation question/answer sets. The system can provide opportunities for them to add this data, but it shouldn’t be required.
As the level of investment increases in terms of time spent on the system, data entered (social networks, forums) and data generated by the system (ratings, suggestions, logs) or critical data is tracked by the system (credit cards, bank statements, online billing) the need for the user to access the account increases. Abandoning the account hurts, and may not be an option. When investment is high the system should require additional validation information such as alternate email addresses, and validation questions.
The system should be sensitive to the individual user’s level of investment and provide appropriate levels of requirements for validation information. As soon as they add a credit card to the account, part of that set-up should be validation questions and a secondary email address. It it’s direct control of a user’s money, the pain of entering in additional validation information is acceptable because the pain of the compromised account is significant. If the investment is increasing time, the system may begin with unobtrusive invitations to add additional data to the account, and increase frequency and prominence as more time is invested by the user.
It is better if users provide their own verification question and answer, as the question/answer will be personal and more easily remembered. The use of user generated questions also provides an extra layer of security. Harvesting of particular data categories like mother’s maiden name will rarely provide hackers with useful validation information.
The ability to change data
Allow users to change their login ID. Bank of America still forces me to use a login from 8 years ago, there is no way to change it. I have to remember what domain name I was using 8 years ago in order to get it right. I shouldn’t have to work this hard. It’s my login let me change it to something I can remember.
Updating validation information
Validation information like alternate email addresses and validation answers can change. People leave jobs, get other Internet service providers and their pets die. Sure information about the distant past is unlikely to change, but it’s also harder to remember. The system could send out an email or prompt a review of validation information once a year. The email could simply state what the email addresses are which are attached to the account and relay the user’s self-created validation questions. If the user still has access to the email addresses and still remembers the answers they can ignore the message. If they want to change them a handy link is provided. The self maintenance of the data will keep it fresh and accurate.
Users should be able to reset passwords using any email address attached to their account. Entering in the email address should send a message with a password reset link.
Should the user be unable to access their alternate email account(s), they should be able to identify their account and answer the validation question(s), and then reset their password. This is how Yahoo! operates. It asks for some basic validation information (which for many people are details which can be found online). If the correct information is provided Yahoo allows the user to change the password in the next form field. As many bloggers have pointed out this is not as safe as requiring the reset link to be retrieved from another email account. The problem is that there are times when someone won’t be able to use another email address.
Returning to the idea that as a user’s investment increases the level of security and validation should, there is a solution to the problem. In the event that the person is using the email address as their main email address the validation and security requirements should be higher than if they use it just to sign up to newsletters. A simple version of this might require the user to answer a single self-constructed validation question for low investment and many of them for higher investment. Asking about details such as last login, services attached to the account, last password remembered, and possible email addresses or other personally known data about the account give the system a contextual set of questions, constantly changing but always available to the account holder. Greg Hughes gets deep into additional security measures which could be implemented as the level of investment increases, so I won’t go into it here.
Recovering user IDs
The login ID is identification, not authentication. In cases where people use their email address as their login, it’s not a secret what their login is. Anyone who knows my gmail account knows what my gmail login is. What they don’t know is my password. In the services reviewed above the opposite thinking seems to have gone into their recovery systems. Getting a password reset is as easy as knowing the login. Getting the login at worst isn’t possible, and at best requires significant amounts of data like last login, services attached to the account, networks joined, and last password remembered.
Recovering the user ID is critical, but not for security reasons — it shouldn’t be a game of hide-n-seek. Users should be able to recover their ID by either typing a user ID to see if it’s in the system or by providing enough personal details for the system to locate and retrieve the correct ID. Forcing the user to retrieve the user ID from an email to a secondary address needlessly complicates the process. If they knew which email address to check they would have known what their user ID was.
Strong password requirements
Because the password is the primary authentication element it is important that the user require the user to create a strong password. Some systems also use security questions to authenticate as well. The user should be allowed to keep the password for as long as they want. Forcing the user to create a new password doesn’t help their ability to recall it, so they compensate by writing it down or keeping it in a text file on their computer — voiding the point of changing the password.
Handling multiple claims to the same email address
While email addresses for the most part remain under the control of a single individual the system must be able to acknowledge that more than one person may control the email address over time. When a user adds an email address to their account an email verification should be sent out to confirm that the email is under their control. If they confirm the address should be added to the account. When the user leaves the job to which the email address is attached it will remain attached to their account. If another user later is assigned the same email address and tries to add it to their account the system should allow them to add it, contingent on conformation. The second user will receive the verification email and confirm they are now in control of the address. The system should flag the first user’s account. The next time the first user logs in using this email address the system should prompt them to either choose another email address for communication (if they have another on file) or should require them to add another email address before continuing. They can choose to keep the email address attached as legacy data, but cannot use it actively now that someone else controls the account.