Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I have an idea to simplify the login screen on things like home computers with a small number of users (say, 2-10) with passwords.

Today, a typical home computer's login screen has three steps:

  1. Select a user. In the 2-10 user case, this is often done with a set of icons you can click.
  2. Type the password.
  3. Click OK or hit Enter.

What if we eliminate the first step? Then the login window could start with the cursor in the password entry field, ready for any user to type their password and hit Enter. Once that's done, that one password would be checked against all registered users on the machine (remember, there are only 2-10 to check), and if any matches, the login succeeds. If none matches, the process either starts over, or reverts to an "old style" screen where the user can click their icon if they forgot their password (just as today).

I'm hoping for an answer in one of two categories:

  1. A substantial example where this has been tried (whether successful or not).
  2. A substantial reason why this would be a bad idea.

I'll note that my proposal does make some assumptions:

  1. 2-10 users. This is pretty much the same assumption as current icon-driven login screens have, I think. This new way might scale a little better, say up to 20-30 users, whereas that many icons on the screen would be confusing.
  2. Unique passwords. This may even be an advantage: the system would enforce password uniqueness to let the scheme work, but if two users had the same exact password before, chances are it wasn't a good one.
  3. Every user has a password. If not, perhaps the old-style icons could be displayed with reduced prominence along with the password prompt--that'd be OK with me.
share|improve this question
10  
With a username/password scheme you can only test one password against one account at any time. With a single password scheme, you'd be testing the same password against every account every time. –  zzzzBov Jan 15 '13 at 17:17
28  
Keep in mind that having passwords only would also prevent you from disabling an account for too many bad logins. –  user606723 Jan 15 '13 at 18:14
10  
Where security is not a concern, users can opt to not have a password at all, and log in with one step: click on the user icon. For example, a family PC used mostly only for multimedia, and the different user accounts only used for personal settings like colors, icons, etc. In this case, you made the login last longer, not shorter. –  vsz Jan 15 '13 at 18:59
5  
The same question was raised by this site's founder several years ago. The comments are interesting. codinghorror.com/blog/2005/10/… –  Patrick McElhaney Jan 15 '13 at 21:49
2  
For the security perspective, see Using only password to authenticate user (no “username” field) –  Gilles Jan 16 '13 at 20:23

17 Answers 17

One reason why this might not be a good idea is that you would have to enforce unique passwords. This does not seem like a big issue to user experience at first, but from a security point of view, this is critical, here is why:

Enforcing unique passwords means that when a user picks a password there is a chance they accidentally (or with malicious intent) uncover another password reserved for another user on the system. The user then knows that the password they tried is in use and what's worse even, with this system, there is no need to know which account the password unlocks. Just logging in with that found password opens an account.

You might argue that the chance is infinitesimal and this is for a small setup like home use anyway, but the fact is that with security a flaw in the system is the root of all evil.

share|improve this answer
4  
Maybe if another user guesses your password, the system should "burn" that password, forcing you to authenticate via a secondary method (the "forgot password" way, aka "mother's maiden name" or whatever). It could prohibit both the old and new users from using that password ever again, because it was proved to be insecure. Does that satisfy you? –  John Zwinck Jan 15 '13 at 13:23
6  
I am not really in favor of this idea either, but this objection could be worked around by having the system assign passwords. This has pros and cons, but I suspect overall usability would go down. Most users would rather choose one of the 2-12 icons and type in the password (of their choosing) rather than memorize a system assigned password. –  emory Jan 15 '13 at 14:14
3  
+1 Indeed! Who is going to enforce a time-delay or max-retries limit for password failures on a registration screen? Probably nobody. –  msanford Jan 15 '13 at 17:58
6  
@hydroparadise xkcd.com/936 –  Patrick McElhaney Jan 15 '13 at 22:01
4  
@JohnZwinck: that's still not workable, since most people still use the same password in multiple places on the web. If you know who in the household the password probably belongs to you are, for many people, now able to access their email accounts, bank accounts, etc. –  Kit Grose Jan 15 '13 at 23:22

Only problem with your idea (or maybe you can help me visualize) is

-- How will user select himself and type the password?

If you really want to simplify, you can

-- use bio-metrics based authentication like face recognition on Lenovo and finger print recognition on Toshiba

-- 3X3 matrics where you would join the dots in a specific way to login (used in hand-held devices)

-- Unique key combinations (upto 6 keys assuming both hands could be used and 3 fingers for each hands at once)

share|improve this answer
2  
The user doesn't "select himself" - the whole point is that the system knows which unique user is logging in because (by construction) only one user can have a given password. –  John Zwinck Jan 15 '13 at 13:23
    
So how do you ensure that passwords are unique. Since if you tell the user than other user whose password is duplicated will not be secure anymore. Also changing the password will change the user too. –  ripu1581 Jan 15 '13 at 13:29

If you choose to have a password only log in, you will run into many problems.

Security

If you only require a password, you have no way of knowing who it is that you are logging in unless you enforce unique passwords. In that case, if I were to sign up and tried to use a common password (say "Password") and your system told me that it was not allowed, you have basically given me someone else's full access information.

If you choose to assign passwords, this becomes potentially harder to recall than a chosen username / password combination. Which is poor UX and security because it is almost certainly going to be written down somewhere unsecure.

Usability

This is one area where there may be a weak argument in favour of a password only log in, simply because it's easier. However you provide poor security and highes risk in exchange. What is to stop me from simply trying to enter lots of passwords to see if they work? You could follow mobile phones examples and lock the account after three incorrect attempts, but then how do you unlock it without a username or a second longer password (like a PUK code) which is even harder to recall than a username in the first place.

Usernames and passwords are one of the most ubiquitous features of modern computing, and people have (rightly) come to expect them both to be there. If a system has only one, you are very likely to confuse people who will be looking for both.

Summary

Using only a password for logging in provides very little benefit, and creates many problems. I honestly can't see a single use case in which this is an acceptable solution.

If you would like an alternative to passwords for logging in, take a look at Alternatives to passwords for authentication. However you still need to know who you are authenticating, and hence a username needs to be either implied or given.

TL;DR: Don't do this. Ever


Edit: Major update explaining points in more detail and including information from the comments.

share|improve this answer
6  
This answer gives some (very) big assertions. Where is the evidence that "It is very poor security and very poor usability"? –  LarsH Jan 15 '13 at 21:20
2  
@LarsH The poor security is a fact that anyone dealing with cryptography or security will confirm. The usability is based on changing a system that everyone that uses a computer is used to. –  JohnGB Jan 15 '13 at 22:21
3  
But OP started saying "I have an idea to simplify the login screen on things like home computers with a small number of users (say, 2-10) with passwords." there you have device / username. (Anyhow, I don't pretend to argue on this, just pointing that we are using it many times for single user devices) –  OnaBai Jan 16 '13 at 1:41
4  
@JohnGB: your arguments may have some merit, but they don't come close to justifying the drama of your headline. –  LarsH Jan 16 '13 at 2:06
3  
I'm sorry JohnGB, but from a cryptography standpoint this answer is entirely wrong. Guessing the passwords of users is possible in an explicit-username system equally well - it's no property of a password-only system. Furthermore, building a cryptographic security argument saying that something is unsafe because someone used the password "password" is a void argument, because it is trivially true. And from an UX perspective I disagree with your answer. For example an online image hosting service can provide a "password only login" for the uploader of an image to delete a file later on. –  nightcracker Jan 17 '13 at 1:20

Interesting idea, let's analyze its parts.

EDIT: I'll state outright that I'm not really a fan of the idea for the reasons kontour stated (enforcing unique passwords exposes existing passwords to new registrants).

n-factor authentication

As others have alluded to, the trend in security has been to increase the factors required for authentication. It's currently in fashion to require "something you have and something you know" (like a username + time token, see below).

However, there are plenty of examples of single-factor authentication that are already in use today:

  1. The key to my house.
  2. The door code to my office.
  3. My alarm code.
  4. Many biometric data-based authentification mechanisms (such as a fingerprint of facial scanner, which replaces - rather than augments - the username + password combination).
  5. Even credit cards (for small transactions). True, it's a slightly different paradigm: it's allowed because the potential damage footprint is fairly small. Still, it's worth noting.

The reasons these work is that the statistical likelihood that someone else will have the same token - face, fingerprint, physical or numeric key, etc - as I is acceptably small.

Note that in a home-computer environment where a user is selected from a predefined list of people, no additional security is really added: the attacker already has a complete list of usernames. And, really, the security gained through obscurity is usually trivial.

This is why the default behaviour of the Windows fingerprint reader authentication mechanism is simply to allow you to swipe your finger: it will authenticate whatever user that print is registered to.

Token duplication

Authentication tokens can be duplicated, whether they are a physical key cut at Home Depot, or an RSA SecurID time tokens (by stealing the device / social-engineering someone to read it to you).

As far as I can recall, there is currently only way to harden against that attack vector: increasing authentication factors.

share|improve this answer
5  
Your first 3 examples are not examples of single factor authentication. The key to your house is two-factor (you need to know both the address and have the key - your key alone does not help you get into your home if you don't know which house is yours. In his example he effectively wants to create a key which would let you into whichever house it was for AND reveal which house it is for, all at the same time. The OS will effectively try the key in every lock on the road simultaneously, then tell you which one it worked in. –  NickG Jan 15 '13 at 20:21
1  
@NickG: I see your point about house keys, but the same could be said about the proposed password-only login scheme: you still have to know what computer (or domain, or web site) to log in to. So the proposed scheme is not necessarily single-factor any more than house keys are. It depends how much context is assumed. Here, the context of a particular computer is assumed, but it need not be. –  LarsH Jan 15 '13 at 21:23
1  
Indeed: they system proposed only requires that you have any key and it will automatically point you to the house it unlocks, if any. –  Sklivvz Jan 15 '13 at 21:23
1  
@NickG Of course they're single-factor. The thing you're authenticating on is not commonly considered one of the authentication factors. I consider the first three to be paradigmatically identical to the fourth insofar as I (1) need to know which computer to authenticate against (the address) and (2) have a valid biometric identifier (the key). Furthermore, the biometric data alone determines which account I am authenticated for which is analogous to searching for a house with a given key (if you consider accounts to be like houses). –  msanford Jan 16 '13 at 3:16

A reason that just providing passwords could be problematic is in system administration. By providing only passwords you are making it difficult for the administrator to get a handle on the account. Thus while each account may have an account number, the admin won't be able to easily relate that to a user.

e.g.

  1. User: "I have a problem with my account"
  2. Admin:"Okay, what's your account?"

How would the user respond to that.

Another reason against it would be in the context of account recovery. What would you do if the password had been guessed by a malicious user and that malicious user had changed the password. You would have a similar problem if the user forgot their password.

share|improve this answer
3  
You will have an username, you just won't need it for login. –  Chris Jan 16 '13 at 7:31
1  
@Chris from the user's point of view, it wouldn't exist - so it would be of no use in the situation described. But that's OK b/c in the OP's situation (home computer): I'm dad and I have root access. If my son has problems logging in, he can just tell me and I can easily relate that to a specific user account. Still not a good idea. –  emory Jan 16 '13 at 12:56
    
Then ask for his name, which he entered when he registered his account. I don't see your point. –  Chris Jan 16 '13 at 13:03
    
@Chris why can't the user just input the password twice and press a "Create New Account" button? The system will validate the passwords match (and are unique) and create a new account. Then whenever the user types in that password into the login screen, login occurs - the system does not need to know what the user calls themselves. –  emory Jan 16 '13 at 21:56
1  
The responder has clearly not read the original question. The OP is not suggesting there are no usernames at all, he's only suggesting you don't need to ask the username at login. I do not understand how this is voted up to 20. Now I'm wondering if 20 other people have also not read the question?? Or have I misunderstood myself? –  NickG Jan 17 '13 at 10:43

This happens all the time on the web, it's called a cookie!

Also, sometimes, an invite code, whether single-use or multi-use.

The only downside is it gets harder to account authentication failures, if the "password" doesn't match, which user do you account that to? On the web, that's usually put to client ip address.

share|improve this answer
    
+Chris, yes of course I read op. This goes to "substantial example where this has been tried"; If you must have an example of same device in a conventional sense, think internet kiosk or internet cafe. These sometimes use single numeric code, effectively password-only authentication. –  qarma Jan 16 '13 at 8:46

Because on a system of any size, the chances that you can guess a password that someone registered with the system is using is extremely high.

OK "password" may be forbidden as a password, but is "pa$$word"? Or "pa$$w0rd"? Or some case variant of those? How many people are using normal dictionary words as their passwords (with a single capital letter and possibly a number added to satisfy the 'password strength' requirements). Attacks in which there is an automated attempt to try dictionary words (with some additional capitals and numbers) as passwords against a given known login are often effective. If you can essentially simultaneously try those guesses against ALL USERS of the system, the chances of success are...well, virtually 1!

This means that the chances of an attacker being able to log on as someone to your system is virtually certain. So you may as well abandon security altogether and allow anyone to access and change anyone's information. Which would almost certainly reduce your number of users.

share|improve this answer
    
I did stipulate that the proposal was for systems with around 2-10 users. I think this addresses your concern to a large extent, including the last part, about "reducing your number of users"--surely your family members won't abandon their accounts on your PC because of this! The whole idea was never intended for environments with hundreds or thousands of users. –  John Zwinck Jan 19 '13 at 14:00

This wont be a big problem in terms of username+password combination because in the opening page, we see all the users name in windows which is almost equal to the proposed idea.

There are around 100^5 different possible password having 5 char. If password are unique and formed of 5 char, an attacker would have 10 out of 100^5 chance to be verified in each trial, whereas in the proposed idea, in a network having 10 user the for each user there is 1 out of 100^5 probability which are almost the same.

So the biggest problem is not username+password combination, bigger problems are said by Kontur

share|improve this answer
    
In practice a five-character password is much more likely to be something like abcde, asdfg or 12345, than h$Rl3. That drastically reduces the problem space. –  Michael Kjörling Jan 16 '13 at 13:10
    
yeah, you are right, but in both cases, the reduce is same, so I just ignored the probability of abcde usage and h$Rl3 issue. with a good list of passwords a bruteforcer could enter a system much more easier than random password trials –  tusherity Jan 16 '13 at 13:24

The key problem is that this would require insecure password storage and/or a significantly longer login time. Password storage should be a salted hash of a password. Without knowing the username, it is not possible to tell if a password is valid unless you try the password against every user you have. It might not take crazy long to try it against all of them with a small number of users, but that's still making the login process take longer than it needs to, particularly since a well defined password hash should be time consuming to perform to ensure it can not be easily brute forced.

An alternative would be to find some way to embed the identifier in the password, such as using the first few characters as another user described, but then it brings up the question of what is being gained now that the user has to have a password they can't fully choose (and which will probably be obvious to them that they are getting a "username" as the beginning of their password). At that point, it's probably better to simply let them choose their username and not much is gained by having them both entered on one line.

The key is that an identifier and secret will always be necessary from a security perspective since secrets should be resistant to offline attack and thus must be time consuming to check. There are lots of ways you can try to imply the identifier to make it easier on the user, but many of those also have their own drawbacks. It does depend on the exact use case though.

share|improve this answer
    
I addressed this in the question by stipulating that the proposal was for systems with roughly 2-10 users. Of course passwords would not be stored insecurely, and on modern computers the time required would be imperceptible. –  John Zwinck Jan 19 '13 at 13:50
    
@JohnZwinck If the password is stored securely, supporting 10 users should make the login process take about 10 to 15 seconds. The password hash should be time consuming to prevent offline attacks against the hash. This hurts you very badly when you have only the password to work from. Since the password hashes need to be salted, you can't simply hash once and reuse the value to look it up. –  AJ Henderson Jan 21 '13 at 14:00

Some people have multiple accounts for keeping files separate but use the same password (a security weakness, but I say one good password is better than multiple weak passwords). That would break down in such a system.

The password could be extended with a pseudo username but that seems to defeat the purpose.

share|improve this answer

This was suggested in 2000 by Jef Raskin, and it was implemented by Amazon for at least a couple of years. It's a good idea, and no less secure.

The reason it's not less secure than a username and password is because your username is probably guessable. It's your email address, or your first name, or your first initial plus your last name, or it's the same handle you use on other sites. Only the combination of your username and password is a valid login, which really means you could do a login that was "usernamepassword" as one long string and it'd be just as secure. Raskin argued what the OP argued, that you could just have a password in that case.

Section 6.4.3 in The Humane Interface is titled "Simplified Sign-ons" and covers this in more detail. (People replying to this comment should respond to Raskin's description and argument in whole, not to my summary of it.)

Amazon rolled it out around the end of 2009, beginning of 2010, as their "PayPhrase" checkout system. A PayPhrase was a globally unique, long string, which was attached to a billing method and shipping address, to speed checkouts. It also required entering a PIN (digits hidden as you entered them) to confirm the order. PayPhrase, intentionally or not, was an implementation of Raskin's "simplified sign-ons," with the added security of a masked PIN in order to prevent shoulder-surfing of a customer's unique phrase, which is the one understood weakness of visible phrases as the sole authentication mechanism.

PayPhrase was phased out a year ago, but security was not cited as a reason, nor would I expect it to be.

share|improve this answer
4  
Of course in that case the users had no choice of their PayPhrase but had to use a predefined (and by design unique) one, which would fix the biggest concern. However, the user would then have to write it down or store it somewhere due to the probably unrememberable-ness, and then you could just switch to SSL or token authentication directly... –  Tobias Kienzler Jan 16 '13 at 9:31
    
PayPhrase only offered you suggestions; you could provide your own phrases as long as they were globally unique. –  Vitorio Jan 17 '13 at 13:41
    
So if you happened to receive something like "You cannot use that phrase" you could just try and use that phrase to pay at someone else's costs? –  Tobias Kienzler Jan 17 '13 at 13:53
3  
No. PayPhrases were attached to billing methods and billing addresses, and require the entry of a PIN. If you improbably guessed someone else's PayPhrase and PIN, you would be sending them a book using one of their own billing methods, to one of their addresses, which they could then simply reject on delivery, or return. This was covered in my original answer, and as explained by Amazon for the length of the PayPhrase rollout, and easily rediscoverable by looking for old articles about PayPhrase. –  Vitorio Jan 17 '13 at 21:41
1  
This isn't really a valid argument for this case though as without the PIN payphrase would be completely impossible to implement securely as there would be no secure way to store the payphrase. Effectively, the payphrase is an elaborate username while the pin is the password. –  AJ Henderson Jan 21 '13 at 14:31

I don't see why you couldn't do this for a small amount of users to simplify things.

However, downsides are:

  • Users cannot make up passwords, the system or system admin has to generate a password that is unique. If users do it, they could collide. So there could be a maintenance issue if you are a system admin. Examples if a user forget or wants to change the password, the admin is going to have to do it. But, if a small amount of users, should not be that big a deal.

  • The system admin will be able to log in as anyone. For a typical username+password combo the user admins know all the users of the system. User names are not secret or unknown. Everyone can pretty much figure out each others username. You might even notice your neighbor's user name when they log in since it is not masked. That is NOT the secret. However, the password is. Everyone has there own little secret, the password. Since everyone has there own secret (password), admins cannot log in as other users. So, just using a password, the admin will know all the secrets, or there will be no secrets. So admins could impersonate anyone. If this isn't a big deal (admin being god) then it could be simplified as you suggest. In most systems this is a big deal.

So, typically for system logins usernames and passwords are used because we want each user to be able to provide a piece of information that only they know about (secret).

For just using password, I can give an example of a device with a parental control. The parental control just uses a password, no user name involved. For example, we don't want little Johnny spending $500 on mommy and daddy's credit card purchasing in game swag using one click payments. In that case, only the parents know the secret password, so typing in a user name is not important and/or redundant.

share|improve this answer

Here's my two cent:

Using login credentials where you login in with a password only is (as someone else here has said) like having a secret username. That being said, if you don't want to use a username than there is a way you can use a password-only login without compromising security. You could use a fingerprint scanner that authenticates the identity of the user before they enter their password. Or you could install facial recognition that will do the same thing. Granted, facial recognition technology is still in its infant stages but it's an alternative to a username.

I should note that no matter what authentication method you use, a username-less login system can raise system administration issues if you don't have a full understanding of the technologies you have in place, but I think others who have provided answers to this question have already gone into detail about the implications you could face.

share|improve this answer
    
I wasn't really thinking or proposing that usernames would disappear entirely. And they're hidden today already! On both Windows and Mac OS, there is a "true" username which usually doesn't change (e.g. "jsmith") and then there is the display name which can be changed by the user easily (e.g. "John" or "John Smith"). –  John Zwinck Jan 19 '13 at 13:57

If your goal is to limit clicks and data entry to just a password and button, setup a family type of login. Sort of like verifying an account for an unknown password, have them answer a series of questions. The questions are randomly presented to the user at each login. All they have to do is provide their answer (bad because they have to remember several passwords/phrases, but good questions will help)

To manage duplicate answers, your random question selection algorithm could exclude those questions where family members failed to provide the correct answer.

Another choice would be to just list all users with a password box next to each name and a login button. A parent/admin could set this up as an option.

share|improve this answer
    
Asking different questions on each login is not going to be good UX for regular users who would otherwise use muscle memory to log in without even thinking about it. –  John Zwinck Jan 19 '13 at 14:06

This is not secure, because other user will know about others' password accidently. If a password is auto generated by the computer and users can't change it then it is secure. And the system has to change and inform about a new password after 5 or 10 logins.

share|improve this answer
2  
Your answer is basically just repeating what Kontur has already said (currently the top answer). Can you explain why your answer is different? –  JonW Jan 16 '13 at 7:12

It is possible to make such a system work reasonably well if some portion (e.g. the first one or two characters) of the "password" is required to be unique; preferably, that portion should be forever uniquely bound to the user account in question. For example, if one will never have more than 26 accounts, one could require that the password for user #1 start with "a", the password for user #2 start with "b", etc. This would mean that what looked like a 4-character password "magic" would in reality be a one-character account id "m" and a four-character password "agic", but the user could enter the whole thing as a single five-character entry rather than typing the two parts sequentially.

This approach wouldn't be completely transparent to the users (since they'd be told what the first character of their account ID had to be) but would still allow them convenience of typing a single 'word' rather than having to type 2, and still allow them to change their passcode (other than the first letter) at will. Using this approach, the effective strength of each passcode would be reduced by the number of characters used as the account id, but in many cases that wouldn't pose a problem. Further, if user #11's favorite password would be "fnord", he could always if so inclined use "kfnord" as the password on this particular system in which case the number of characters he types to log in would be one greater than the number of characters in his "real" password, but typing that extra character would spare him the requirement of entering his username via some other means.

share|improve this answer
    
This is an interesting suggestion. How you communicate this requirement to the user might prove troublesome though. –  JonW Jan 17 '13 at 17:16
3  
@JonW: "You can pick any password you like, so long as it starts with 'k'". –  supercat Jan 17 '13 at 17:17
    
Haha, OK I take it back. Apparently it's not really troublesome at all! –  JonW Jan 17 '13 at 17:27
    
I thought of almost the same approach, just with longer account ids. If you choose a id length of 4-6 or so, the user would be able to choose his own id (=any password he likes) with little chances that it already is taken. Downside is that user ids aren't hashed, so the id may give hints about the pattern of the real password part. All of this would be dangerous when common passwords are used... on the other hand there could only be a single user with the password 'password', so it may even help people to reconsider and choose something more secure. –  kapep Jan 19 '13 at 21:28
    
Oh and for your approach with just a single char id, you should take upper/lower case and maybe numbers or special characters into account, that would allow for more users than 26. –  kapep Jan 19 '13 at 21:30

Essentially there is no flaw in your concept, except for the fact that people would use a keyboard to type in a password. The main problem is that a human would be typing in the password and humans tend to make things easy for themselves. A key sign in would do the trick. Keys would beat the security flaw that keyboard password sign in's create.

In terms of having to check every other users password, that doesn't need to occur. A simple unique hash could be created from a fraction of the key taking the place of your user. A lookup table would find this hash, then use the rest of the key to enter the system. This way if a hash is already in the table, it could be forbidden without giving up the key of an existing user.

share|improve this answer
    
You don't need to split the key into an user and a password fraction. It won't make it more secure. –  Chris Jan 29 '13 at 10:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.