I think this is almost a good idea except that:
The problem everyone already mentioned, I try to create a new user called “a”, it says error, name already in use, i log in with “a”.
If my login is “b” and I accidentally type in “a”, it gets input password asterisked I get logged into the system as another user “a” and worse the password was hidden so I can’t tell and the system can’t print it to the screen after I am logged in, in case someone is looking over my shoulder.
If I’m logged in as user “b” and I want to email/message/interact with another user, how can I find out their username without knowing their password? Or would each user still have a username, just no on the login screen?
I like the idea of streamlining user interfaces, but this example is inopportune. Furthermore, I am not convinced it would work.
Having just read the December 06, 2007 posting I am concerned that multiple pass phrases would result in the same hash. If this occurred, you would have no way of differentiating users with the same hash because the hash would map to multiple user names. You would have to request other information from the user to disambiguate (which opens a security hole) or you would have to require unique hashes. Requiring unique hashes would partition the space of pass phrases into equivalence classes based on their hash. Therefore, the number of meaningful pass phrases is bounded by the number of unique hashes in your hashing system. This also means that your method of picking unique pass phrases based on a set of words presented to the user is not guaranteed to work.
There are also other limitations to creating unique pass phrases based on a set of words presented to the user. I read recently that there are about 50,000 words in the commonly used English vocabulary. Given that nobody wants rare words in their pass phrase that they do not know the meaning of or how to spell, the system is limited to (roughly) 50,000 users if each pass phrase must contain at least one unique word. This is clearly not a scalable solution.
Even if providing a pass phrase to log in would work well for scenarios with small numbers of users, I see this method as inherently insecure, and therefore unsuitable for use. Successful security is grounded in mathematics and computability theory, and such justification has not been provided for the proposed method.
I am surprised nobody has mentioned performance. I do not see a difference between looking something up by a username and looking something up by a hash value, but there may be scenarios where looking up by one or the other gives some benefit. This would matter for servers processing many authentication requests.
Does anybody know the original reasons for choosing to incorporate a username as part of authentication?
Odd that no one seems to remember the multiple uses for a user name. The sense of self and identity in the system. It is also a reference for other people. A public identifier. So may be you don’t have to enter it on login, but people could forget or never know what there id is. So you would just /home/password or work up some other odd mechanism. You have to know who you are and others are in the system.
Authentication is only one part of the equation.
There is also a challenge in that users often have multiple IDs, this would be a large design change for any OS. There are many larger usability issues that should be focused on.
That’s why, with regular Windows XP, You can change the logon UI screen to display the username and picture, but when they are clicked on, it shows only a password field.
several problems here: if user2 chooses the password of user1, you cannot give him the password, but you also cannot say “password already taken”, because then he can “hack” user1.
And you cannot send the forgotten password to the user, if you do not have another handle.
But maybe openid is something for you.
As many pointed out - the username is needed to correctly (from security standpoint) resolve the conflict with same password entries.
But let’s start from the begining, let’s think about why passwords have been invented. Remember the medieval towns? Anyone who knew password had permission to enter. So, effectively, there were perfect username/password there. Town name and password. In our case, the town is your account, with the population of one. So, username is not security per se, it is just an address of your own town.
Remove the passwords - and you have access to all towns. But, remove the address - and you have access to all towns happened to have the same password. The probability of hacking the latter is much lower, of course, but it is much higher than in case of having pair address/password (and this one still is not zero).
Now, here is the interesting part. How did they programm in Dark Ages? Suprisingly, they did not ask - what password do you prefer to enter our town X. Quite opposite, they told anyone who is potentially allowed to enter - that from 6 pm until 6 am in the January the password to access the town X will be “Jeff Atwood strikes again”. And this is the only way this approach can work - user see what password would be to access his account (catchy phrase, choice from set of phrase - that’s all implemntational details).
Unfortunately, what worked for Dark Ages, does not work for us with six billons people accessing 108810358 websites. Imagine, that you have to remember a score of phrases for just your credit cards accounts.
So, at the end of the day, the combination of your account and the password looks much more elegant and simple and secure solution. And if you don’t want to always enter address of your town - there are much more simple ways, like “remember me on this computer”.
Without usernames it is much easier to for dictionary attacks to break into the computer. You just need one password and you have access. If you have a large userbase (imagine yahoo mail), you just type in several passwords and eventually you will be able to login in somebody else’s account.
How many people here would make their pass phrase: “For the Horde!!”
I probably would. And I would definitely try it to log into someone else’s account.
Hmm… Jeff has a point.
ONLY
if ‘removing username’ is limited to the login dialog box.
Username is still necessary.
My family’s computer, for instance, is used by 4 different individuals. Every now and then, 3 of them (the less-IT-oriented ones, to put it mildly) will have some trouble, and I have to get in there with ‘administrator’ (there’s yet another username 
) and fix whatever happened under their folder in “C:\Documents and Settings”.
No way I can do that if I don’t know their username.
So, final words: Usernames ARE necessary. But login dialog boxes FOR A CERTAIN COMPUTER, LOCAL LOGON may do away with usernames.
Other than that particularly singular case, no way, no fricking way you can get away (pun!) with removing the username.
Anyone pointed out the birthday paradox yet?
http://en.wikipedia.org/wiki/Birthday_problem
The problem of collisions gets considerably worse if you have no user names to prevent birthday attacks.
Sorry to post 2 years after the debate was closed, but the mathematician in me is hurt: a 21 characters passphrase is taken out of 70^21 (=5.58e38) choices, not 21^70. And a regular password is taken out of 90^8 (=4.30e15) choices.
Another issue: computational speed of the hashes.
Most systems do something like concatenate the username with the password (and perhaps some salt as haacked mentioned) and hash the resulting string. This string is then compared to the stored password. This takes 1 hashing, and 1 comparison if the password is correct.
With this new approach, every username in the system should be concatenated with the entered passfrase and hashed to find out to what username the passfrase belongs. On my linux box it takes 25 seconds to make 1000 sha1sums. I do not want to wait 40 minutes to log on to a system with 100.000 users :).
Err, I of course meant that the calculated hash (of the username+passphrase) is compared to the stored hash. (And I can’t spell phrase)
Minor correction to the math, yours too Florent.
Passphrases aren’t as good as you might hope. The problem is that they are generally in English and the entropy of english is only about 12bits per english word. With english words averaging 5 characters (plus a space) this would mean a 23 character passphrase is only about 48bits or around 10^14.
Randomising some words and adding other characters helps but in the end memorable passphrases are a very small part of the passphrase space.
Based on this a 128bit passphrase would have to be at least 10 words or 60 characters including spaces.
The big question i have is, how about if you use this system for many sites.
I mean the need to use a word provided by the computer is already a big bummer IMHO, since as sfb mentionned, your nice i live at the xxx Poo avenue with my cat randy passphrase will be really worse when you’ll have to add typhon in it. Of course you could just add typhon at the end/beginning, but then you just have to remember one more unique word. Who said password ? If you’re creative, you’ll find a passphrase you like wich makes sense with the word.
And then, you suscribe to another site. Bummer , the unique word you chose is used on this site (and there mathematically, the possibility of such a thing happening is exponential). You then have either to add another random word to your classic passphrase, either to create another passphrase wich makes sense with another unique word.
So in the end you have : 1. Much more letters to type usually
2. Same complexity, or maybe even bigger, to memorize your passphrases once you suscribed to several sites using this system.
But then, maybe the security COULD be better on such a system, but that’s a big could, there no clear evidence of such a thing yet, even if i like the emphasis it puts on security.
Since the complexity is not that small on the user, i also don’t see this system used in conditions where the security is just there to be there, like when i suscribe to a random site, or a spam email adress. I mean, your orange captcha is here to say it ,and it’s indeed true, i wouldn’t care less if someone cracked in my dailymotion account, or youtube one, or any other of the 10 sites i suscribed too. I have a dummy username + password that i use for these sites, that could probably be cracked easily, but i couldn’t care LESS. Even the e-mail adress all theses sites refer to is a junk mail box i use cause i don’t want theses guys to annoy me all the day with crappy e-mails. If i had to remember an UNIQUE pass phrase for each one of theses sites, i simply wouldn’t have suscribed.
That is , most of my accounts are of this type, and i don’t care remembering a few complicated passwords for the remaining sites that really matters.
So the emphasis of your system, if it’s well done ofc, is more on security than on user-friendliness IMO. And if you want security, forget that unique word thingy, give me a good old Username AND a passphrase, and i’ll be happy
(Very late response!)
At the time of password selection, you’re presented with a palette of ~12 totally unique words by the system. These words do not
appear in ANY password on the domain. You must use one of these
words anywhere in your passphrase
One problem with Jeff’s proposal above, is that the system doesn’t know a list of words which are used in the current passwords. Passwords are stored as a hash, not as plain text, so the system won’t be able to read through them to get a list of words. If you try to maintain a separate file of unused words (by removing words as they are used) that file could be used by attackers to determine which words have been used - thus helping with dictionary attacks
I disagree on the “Unique Password” thought.
If a dialog came up making a new password that said: “Another user has the same password. Try again.” wouldn’t I then have enough info to log into the system?
Usernameless authentication would work on systems with few users, but would not scale very well.
I type in “LukeBrownEyes57” and get into my account. Then I type in “LukeBrownEyes67” and am logged into someone else.
Imagine how much more fun dictoinary password attacks would be, if every word opened someone’s account!
From what I’m seeing, I’m not seeing any benefit to removing the username from a login prompt. Here’s a few reasons:
- Workarounds are required for accidental collisions.
- The work around for a collision usually involves the collided user to provide some kind of verification the next time they log in. This verification is only slightly more secure than a username. My mother’s maiden name or my favorite pet’s name is in no way secret information.
- I’m going to make a fairly bold statement and say that most computer users are only logging into 1-2 computers(in a workplace environment), and those computers generally aren’t used by anyone else. When this is the case, our user names are already remembered everytime we log in, so I usually never have to worry about re-typing my username anyways.
- User names will still be needed for permissions and security settings, so why not use the username as a guarantee of uniqueness without any concern with password collisions.
I’m not saying it couldn’t work, but I’m not seeing any particular benefit in removing the username from the validation process. When you consider #3 above, most of the time you don’t have to do anything with the username field anyways, as it was remembered from your last login. I know I don’t have anything to back up my claim in #3, but it has almost always been the case in my experience.
I think perhaps the best way to “remove” the username field from the login would be a “Hide Username” button on the login prompt. This would assume the username currently in the username text box will always be the one used. Then from that point on, the username field would not be shown, unless that same button(now labeled as “Show Username”) was clicked, thus allowing the user to change which user is logging on to that box.
One thought on websites (didnt bother to read every single post).
Wouldnt having only a password field on a webpage allow users to randomly guess? At least with a username and password, these light effort tactics would be a bit harder to accomplish.