The use of usernames and passwords for authentication is not secure! And we have known this for a very long time. Nevertheless, usernames and passwords are widely used, as they are easy to implement for developers. The way we deal with this problem is to blame the user for not using this method correctly and to make halfhearted attempts at either educating users or forcing them into a certain behavior. It is time to acknowledge the responsibility of developers and interaction designers for failing to care about user security.
The “real” security community in computer science is largely concerned with the theoretical security of algorithms, protocols, software, and systems. The human element is often not part of the equation, especially if the user does not adhere to the rules specified.
There is little empathy for people choosing weak passwords, not encrypting their files, being sloppy with installing updates, or failing to take enough care in configuring systems. Typical comments include: “If a person chooses a weak password, they are not keeping their data secure,” “If people don’t know what they are clicking when configuring the router, they should not do it,” and “They never bothered to update the content management system, so they were asking to be hacked.” This is an old view of computing, where the users had in-depth knowledge about the technology they were using. The rapid transition from expert users to ubiquitous use requires a completely different point of view. The vast majority of users will not know what password strength means in terms of information entropy and will not know why some ports on their router are open while others are not. It is a great achievement that people can use the systems without this knowledge, but this also requires the security community and the IT companies to acknowledge that many users will not have even a basic understanding of the underlying technologies.
At the same time, traditional security will always try to go for algorithms, protocols, and approaches that are 100 percent secure, at least from a theoretical perspective. This is important and right for systems that do not involve human actors. Achieving the 100 percent in the real world with human actors is impossible; hence we have to think of ways to make systems as secure as possible, even if they are not 100 percent secure from a theoretical perspective.
If a company that creates conventional products knows that its design will likely harm users, it is either not allowed to sell it, or if it does, it is liable for damages. Conventional products have become fairly secure on this principle. People who buy a car expect that the vehicle will not go up in flames if they have a minor accident. One could argue that ramming another car is the driver’s fault, so it is their own fault if they are seriously harmed. But this sounds ridiculous in this context. Similarly, we do not expect that a person taking a bus will check to see if it has been serviced at the appropriate intervals, if the tires are still OK, and if the driver has a license before using the service. We just assume that the company offering the service has taken care of these points. And in most developed countries, this works well. Companies would not want to put conventional products and services onto the market where there is proof that they are not secure. In contrast, many companies in the digital domain are happy to do so, as this seems to be accepted practice. The majority also assume it is acceptable to shift the blame to the user, in order to reduce the cost for the product or service.
Many of the common authentication practices are known to be unsecure. Nevertheless, many companies ignore this; as a result, there are many websites, services, and software products that rely on authentication that is not secure. There are a multitude of reasons. Sometimes authentication using a simple username and password is just a legacy and no one thinks of touching this part of the system. Sometime it is laziness or deadline pressure on the developers’ side, where the most basic library for authentication is used. In other cases, it is even a usability argument. By using a basic authentication, they spare the user any potential inconvenience and effort, even if this means the user’s data may be easily hacked. However, there is no good reason to put the user at risk! Several of the leading companies are showing that relatively good security combined with good usability is feasible.
Many of the common authentication practices are known to be unsecure.
The following are a set of practices that are known to make username and password authentication less secure. This is by no means a novel insight; however, as people often ignore it, we want to make this explicit.
Asking users to choose a password when they register. When the user comes to use a service for the first time, many companies require registration. This is reasonable, as registered users are a valuable asset. However, asking the user for a password at this point is a bad idea. The user’s primary goal is to use a service. Providing a password is an obstacle; hence, it is likely that they will not give much thought about it and will choose a weak one. A better practice is to ask for the user’s email address and potentially their mobile phone number, as this does not require the user’s creativity and is good enough for registering users. Logging in can then be facilitated by sending them an email with a code every time they want to log in. If a user finds this too cumbersome, they can set a password when utilizing the service regularly.
Not preventing brute-force attacks. Many services still do not monitor the number of login attempts, nor do they limit the speed at which passwords can be submitted. In a real-world environment, one can assume there is a problem or the account is being attacked if someone tries to log in repeatedly. Guessing even a weak password will typically result in 10 to 1,000 attempts. Limiting the number of login attempts to three or five increases the real-world security. Humans also need a few seconds to type in a password. Limiting the speed for login attempts to the speed at which a human can hit the keys increases the time an attacker requires. If limiting the login attempts is not possible, then limiting the speed for login can at least slow down a brute-force attack. Assuming that after the first three failed attempts you have to wait five minutes before the next try, an attacker will require more than three days to test only 1,000 passwords. Combining these monitoring functions with sending out a direct login link over email or another channel does not create much inconvenience. The negative outcome of a brute-force attack for the user would then be to receive an email that they are required to log in. This is much less damage than a stolen account.
Allowing weak passwords. It is understandable that users will often pick weak passwords. The reason: They do not really understand what is at stake or they just want to get the registration done. Telling the user their password is weak has not really solved the problem, either. Forcing people to use complex passwords will lead to their writing it down in a book, emailing it to themselves, putting all their login details in a file on their desktop, or, in the best case, using a password manager. Instead of enforcing difficult-password rules, companies and service providers could just add another level of security for users with weak passwords. If you choose a weak password, you will not be able to log in directly but rather will receive a code via email each time you log in. If this is implemented well, the user will just realize that this website or service uses an additional email to keep them secure.
Proposing trivial password-recovery mechanisms. Some users will lose or forget their password. In order to reset the password, the service must verify that the user is who they say they are. In order to reduce the effort for this process, some companies offer password recovery based on a set of questions. If such a mechanism is offered and the questions are phrased in a way that the answers can be easily guessed or found by social engineering, it is the fault of the one providing the questions, not the one who selected the answers. There are many other mechanisms that can be used for much more secure recovery, such as other channels (e.g., phone message) or social mechanisms (e.g., five friends have to support the request).
Adding functions that require increased security despite weak passwords. Online services often grow in their functionality. When services offer basic functions, users may be happy with a weak password only. Once additional functionality is added, the user often forgets that they have a weak password. For example, in its early days, Facebook was a directory with contacts of friends, probably not seen as critical by many users. Now the service is a communication hub and photo album for those same users. The password set many years back was perhaps adequate for the directory of contacts, but it is no longer adequate for the large amount of personal information and communication that is now in the account. Here the provider should increase functionality only if and when the account is secure.
Industry has pushed in different ways to make security risks the users’ problem and has asked users to be extra vigilant. I think we have seen over the past few years that this does not work well; hence, we should make sure we do not make security the user’s problem.
There are many systems that show password strength at the time when login data is created. People are still using weak passwords. If strong passwords are enforced, people will record them, and this may be unsecure as well. Asking users to change their password regularly has two main outcomes. Either this measure leads to simple rules on how passwords are rotated through, for example by adding a letter or number at the end of the chosen password, or login data is physically or digitally recorded again.
To make the recording of passwords secure, password managers are suggested. Again, theoretically this is a good idea, but practically the managers themselves may often have weak passwords, as people often use them on their mobile devices. In the case that the password manager is opened by an attacker, the damage can be massive.
Single sign-on with Google, Facebook, and Twitter does not enjoy widespread popularity. The concept is difficult to understand for the user and many may not trust it. It is also not easy to know if the service included on a website is really the genuine authentication service or if it is a scam and someone is trying to steal credentials.
Creating a completely secure (digital) world is a delusion. Given that many of the big email providers and mobile-phone software companies are making a real effort to keep users’ accounts secure, I argue that enhancing authentication and having a fallback on email or phone messaging is an immediate solution where companies can make their users more secure. We should not accept the scapegoating of users for weak security! If a company uses unsecure practices such as the ones outlined earlier, they are the ones to blame. They should have to face the consequences of making unsecure products.
There are many new ideas, such as biometrics, in both the security and usable security research communities that could replace and improve username and password systems. But given the many legacy devices and services, username and password will be around (potentially as the weakest link) for a while; hence we should make them as secure as possible and then advance to the many novel ideas proposed. For examples, have a look at the ACM SOUPS conference series.
Having followed many of the data breaches and security incidents over the past few years, I have seen that it is a common reaction to blame the user. The known solutions (see sidebar) are technically not complicated, but they are still largely ignored. HCI people understand and hopefully empathize with users, so we are the ones who should make sure they are not blamed for the faults of companies and service providers.
Albrecht Schmidt is a computer science professor at the Ludwig-Maximilians-Universität in Munich. He works at the intersection of ubiquitous computing, digital media, and human-computer interaction. His research interests are in creating digital technologies to augment perception and the human mind. He has a Ph.D. from Lancaster University. firstname.lastname@example.org
The following recommendations are very simple to implement. Leading companies and services have much stronger mechanisms in place. However, if these recommendations were taken on at large, we would strengthen real-world security.
Do not require the user to set a password, especially not at registration time. Rather, provide a means for using email or phone messaging with one-time passwords.
Make brute-force attacks less effective by limiting the number of login tries and by limiting the speed of login attempts.
Lock the account if the user is at risk. If a user has a weak password and the account is attacked, it is better to lock the account than have data stolen. The inconvenience is minimal if the user is provided with an access token over a different channel (e.g., email, phone messaging).
Ensure that password recovery is not the weakest point. Provide means for password recovery that are secure within the context of the service, for example, by providing tokens over a different channel.
Ensure that the account is adequately protected when adding functionality that is more security relevant to the user.
Companies who choose not to implement even such simple safeguards are willingly neglecting the security of their users.
Caveat: Relying on a secure channel, such as email or phone messaging, is also a risk. However, looking at big companies like Google, Apple, and Microsoft, it seems they make a lot of effort to keep the login secure.
Technically these recommendations are easy to implement. Many Web components and server modules offer this functionality. The system designers and developers just have to use them.
©2019 ACM 1072-5520/19/05 $15.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2019 ACM, Inc.