In The Humane Interface, the late Jef Raskin asks an intriguing question: why do login dialogs have a "User" field?
The first thing that pops into my head with this idea is “What happens when a user’s password change is rejected?” That is, say Bob changes his password, he knows it meets the requirements for length/randomness/etc. because it’s the password he used six months ago (the system forces Bob to change his password every six months, so he just switches between two passwords).
Now Bob knows someone else on the system has that password. He can just punch it into the login form and gain access to that other user’s account. With usernames Bob would have to try around n/2 username/password combinations to gain access to that account.
It’s generally accepted (at least as far I am aware) that the sweet spot between security and convenience is ‘something you have and something you know’:
You have a credit card and you know how to write your signature.
You have your ATM card and you know your PIN.
You have cheques printed by your bank, you know your signature.
You have your username, you know your password.
It doesn’t matter if someone gets your cheques, your ATM card or your username as long as they don’t know your signature, PIN or password. I don’t think usernames are vestigial, I think they still have a place of value.
One point I forgot: if the system uses usernames, passwords do not need to be unique. So Bob would never have known someone else was using his old password.
I prefer the site-specific passwords that I generate using labs.zarate.org/passwd/ or similar. My one master password (plus my public, esay to recover) username gets me in just about anywhere. And if someone just stores my raw password and that gets compromised… no loss to me.
Or you can do what Schneier (etc) suggest, just use strong passwords and write them down. I have a paper record of everything, as well as the PGP’d version on my PC. Just in case.
Passphrases instead have quite a few (other) problems than mentioned: the information leak of “that password is already in use” (really? How useful to know that); inability to disable a lost password in some cases (“I forgot my password”… which one was that?); no ability to log failed password attempts against a particular user; matching inability to lock out accounts that are under attack.
(BTW, your lockout activates on error. I didn’t provide an email address and got asked to resubmit, when I fixed it and retried it said “In an effort to curb malicious comment posting by abusive users, I’ve enabled a feature that requires a weblog commenter to wait a short amount of time before being able to post again. Please try to post your comment again in a short while. Thanks for your patience.” This is a classic example of bad software behaviour - first hassle the user, then blame them for the resulting error.
Nice article. I always like questioning assumptions as it can generate innovative ideas and throw light on other assumptions people make.
Having no username kind of elevates the password to the status of a hardware token. It would be cool if I could swipe my pass, or usb key or whatever and log in. No username is required here either as the hardware token is guaranteed to be unique.
There is a bit of a problem with enforcing uniqueness in passwords chosen by the user though.
So what would the permissions dialog for this system look like?
The password is for authentication, but that’s not the only role that a login sequence plays. Identification (which is generally a public function) is important as well. That’s the role a username plays.
The whole scheme could definitely use a creative approach, but this is a no go.
I honestly don’t care how improbable it would be, I want it to be impossible
You want it to be impossible to hack the system, yet aren’t satisfied with statistical improbability?
You missed my point. I’m not talking about ‘hacking the system’. I’m talking about legitimate users using the system in a legitimate way. The system should never say “sorry, that password is in use by another user.” Which it would have to if passwords have to be unique. (I’m not talking about the specific error message, any password that gets refused during the password change is going to go on the “Is this the CEO’s password?” list.)
I think username-less log on is a nice idea, it just isn’t as secure in legitimate use as a system that doesn’t require unique passwords. Personally, most of my data is secured behind 6-to-8 character passwords used with 2 or 3 logins. And those logins are well-known (sfl, scotfl, sfl621 – and pretty guessable once you know my middle name). So my data is only protected by my (short) password. And I’m okay with that. I know that it’s less likely my 8 character password will be bruteforced than, say, my bank’s computer system getting accessed via some other security flaw. So it’s not the possibility of hacking that bothers me, it’s the possibility of effortless, unintended hacking.
Thus, I’d be (very, very) happy to have auto-filled and auto-completed username fields becaue it would save me having to type the same info over and over. But I still to keep the username fields because it means passcodes don’t have to be unique and there is no way the system will just hand my passcode over.
Basically, it comes down to the system validating user’s passwords as unique. The only way I can see one token login working is if the system generates the passwords. But that requires an algorithm that generates secure, memorable (i.e. meaningful) passcodes evenly and randomly distributed across the spectrum. Which I would love to see, but I’m not sure I will since I don’t think the meaningful phrases are evenly distributed. (But I could easliy be wrong about that.)
Still, I like this system more than a single-token biometric system – I’d much rather lose all of my money and a passphrase than all of my money and a finger!
Okay, here’s a thought.
"Please type a passphrase below. The phrase must contain at least four words, two of which must come from the following list:
Of course, you randomly generate the list of words. You can ensure that each phrase is unique. Dictionary attacks are useless. A user must use a different passphrase for each of his accounts.
You probably don’t need non alpha-numeric characters to ensure security. In fact, you may even be able to fix a mistyped passphrase with a spell checker and ignore punctuation.
Oooh, I have a solution to the accidently guessing someone else’s passphrase problem.
When I try to change my password to “Go Packers” and Bob already has “Go Packers” the system tells me, “That passphrase is already taken. We know who you are, PATRICK MCELHANEY. Don’t try anything stupid.”
The next time Bob types his passphrase to log in, he’ll need to validate that he’s really Bob by typing his email address. He’ll be required to change his passphrase before continuing.
So what would the permissions dialog for this system look like?
The same-- you still have a username, you’re just not prompted for it at login.
They’re hard to guess if I have to guess one user at a time, but not if I can guess every user at a time.
This is true, and as the number of users goes up, the odds of a common catch phrase, even a “long” one, increase a lot.
Still, I wonder how mathematically likely this is if you required the pass phrases to be reasonably long (say, 30+ chars) and have at least one number and punctuation.
Obviously you’d have retry protection on the login dialog. Something like every (n) password failures causes the dialog to wait another 2^n seconds, so by the 8th attempt they’d be waiting 256 seconds, on the 9th 512 seconds, etcetera.
Now Bob knows someone else on the system has that password. He can just punch it into the login form and gain access to that other user’s account.
This is no different than randomly typing in passwords; it’s the same argument as the previous one in different clothing. The real question is, can a secure 30+ character pass phrase (with punctuation and digits) really be guessed in ONE try? Because if Bob fails to guess someone’s password-- that’s his new password. He only gets one try!
He’d have better luck at the login dialog with n^2 seconds between attempts…
Sometimes I use more than one user name on a system. If the password I gave determined who I logged in as, I think I would often find myself logging in as the wrong user.
This is no different than randomly typing in passwords; it’s the same argument as the previous one in different clothing. The real question is, can a secure 30+ character pass phrase (with punctuation and digits) really be guessed in ONE try? Because if Bob fails to guess someone’s password-- that’s his new password. He only gets one try!
First, if I had to remember (and type) a 30 character pass-phrase to access anything, I would be running, not walking to a competing product that ‘forced’ the old-fashioned 8+8 username/password scheme on me. 
Second, Bob wasn’t looking for passwords. He was just changing his and happened to hit one already in use. Yes, this can be made statistically rare, but in a username/password system it can’t happen because passwords don’t have to be unique. There will always be malicious user trying to gain wrongful access. You can’t get rid of that. But you can prevent the possibility of the system just handing the CEO’s password to the new guy in the mailroom. I honestly don’t care how improbable it would be, I want it to be impossible.
For small systems it’s quite workable and in fact I have implemented it in the past in a context where it was only for the purpose of ensuring we had the correct name to ask questions of if a problem developed.
Beyond that, though, it’s unusable. The problem is inadvertent collisions. There’s also the problem of how many bits are used to actually store the password hashes. Lets say we use a 32-bit number for the purpose. In a typical username/password setup that means a 1 in 4 billion chance a bogus password is accepted. Since that’s probably well below the rate of human-factor mistakes it’s not a problem.
Lets try the same system with 100,000 users. First of all we are looking at a high probability of a collision in the hashes even if the passwords are unique. Second, there’s a 1 in 4000 probability of a random password working. Can you say “dictionary attack?”
Now for another problem:
Under such a system you don’t know who a failed login attempt was for. This makes it all but impossible to deal with a distributed dictionary attack. If the attacker has something like a botnet the defender can know that an attack is in progress but is powerless to react other than by denying anything other than local connections.
Finally, I don’t see that you’ve gained much:
To gain the same level of security you must increase the passwords by the size of the username and you must increase the complexity of the password hashing technique. You have moved operator time from typing a plaintext userid to typing a hidden password. You haven’t really saved them characters, though–all you’ve done is increased the typo rate.
P.S. to the above: With a username/password system you type the username in plaintext and thus can see if you’re committing a caps-lock error. With a password only you get no feedback about caps-lock.
"Bear in mind that a simple pass-phrase like “My dog’s name is Jake”, at 21 characters, would take 21^70 attacks (3.59e+92) to brute force.
Understood and agreed, but what I meant was that the majority of people will fall on dictionary based words, significantly reducing the improbability. Instead of doing a brute attack based on letters, an attacker would use words. And if they were really smart, put a grammar check on it to make sure the sentence is valid (which most would probably be).
I like Patricks idea of picking words from a set. I don’t have any idea if the math behind it is sound though.
Of course, brute force attacks would be a moot point if the system locked out after X bad attempts.
The next time Bob types his passphrase to log in, he’ll need to validate that he’s really Bob by typing his email address. He’ll be required to change his passphrase before continuing
I thought about this. Conditionally prompting the collided user for some additional bit of information in the event there is a collision.
Can you say “dictionary attack?”
Not possible, at least not in reasonable time. Remember we lock the logins after failure for 2^n seconds, where (n) is the number of consecutive failures in (m) minutes.
So good luck with that distributed attack…
Instead of doing a brute attack based on letters, an attacker would use words. And if they were really smart, put a grammar check on it to make sure the sentence is valid (which most would probably be).
In my opinion, you cannot build a brute force attacker for pass-phrases. What if my sentence contains out of order words, grammatical or spelling errors? What if it’s not a traditional sentence? What if I use a word only I know? Bear in mind that there’s absolutely ZERO feedback that you’ve successfully partially matched any words. Every mistake is combinatorial-- it’s an all or nothing proposition.
A traditional brute force attacker operates on a per-character basis. But there’s NO equivalent clean unit mapping for sentences-- words and grammatical sentence structure elements. It breaks down all over the place.
You’d have better luck doing an IMDB query for common movie quotes and trying those…
The next time Bob types his passphrase to log in, he’ll need to validate that he’s really Bob by typing his email address. He’ll be required to change his passphrase before continuing.
I think this could work! Many websites ask you for a backup password? Eg, “Secret Question”. What is your mother’s maiden name? What was your favorite pet’s name? What city were you born in?
In the event of a collision, the collided user would be prompted for the “Secret Question” at next login.
The “Secret Question” would also be useful in the event that user really forgot their password. The admin or whoever could ask it before changing the password to some other randomly assigned pseudo-english pass phrase.
a 30 character pass-phrase to access anything
What, you can’t rememember
“I live in a house at 123 Maple.”
That’s 31 characters. Much easier to remember (and far, FAR more secure by several orders of magnitude) than your typical 8 character password. Either that, or you take an inordinate amount of pleasure in typing something like “1-z!Q3%” …
I honestly don’t care how improbable it would be, I want it to be impossible
You want it to be impossible to hack the system, yet aren’t satisfied with statistical improbability?
Well, I don’t want to be hit by a meteor tomorrow, either. But I can’t say it’s impossible.
I like Patrick’s solution of requiring words from a set. It seems to eliminate the possibility of giving away passwords and still lets the user compose a meaningful (to him or her) passphrase that will be easy to remember.
The next step would be to allow the user to unobscure the passphrase during entry (if they feel it is safe to do so) so that (for example) a dyslexic user can get a 30 character phrase entered correctly on the first try. This isn’t as much of a problem with 8 character passwords because each character can be methodically typed individually. 30 character phrases are more frustrationg to enter character-by-character.
But, that said, I feel that my main worry about single-token signon has been addressed by Patrick.
What if my sentence contains out of order words, grammatical or spelling errors?
The example you gave was “I live in a house at 123 Maple.”, which is none of these … I’m not saying it’s not better than “password” or even “123Maple” … but to say it is the same as 31^70 is just misinformation.
Also, given that I’ve been generating random passwords for web sites, for a long time now, I can tell you that there are a significant number that still only allow 8 characters … and probably most only allow 16/32, which cuts down your passphrase a lot (plus it sucks to type that much blind anyway).