Hmmm...

I think it has to do with the herd mentality. Imagine a sufficiently large user base (for example MySpace.com).

Now I go login and start using the "hip" pass-phrases of the day..

"Houston, we have a problem!"
"He's a Family Guy"
"Shut up Beavis"

And perhaps there's a good chance I'll actually hit upon someone's. Doesn't matter if I know who they are.

Although I am all for the use of pass phrases, I also think in community sites, people tend to use common phrases because they're easy to remember.

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.

Of course, by simply adding some punctuation requirements to a pass phrase, this is easily mitigated.

Just a thought, not a defense.

I got another reason for you. Hashes and Salts.

"Ideally", each user record in the database has a unique salt value and passwords are hashed using that salt. That way, if the db is compromised, the passwords are useless in other contexts. (I can't take it and try a dictionary attack on other sites you may have an account at).

Of course, that's probably true if using a system salt instead of an individual salt.

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.

> 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.

> 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.

Asking "how mathematically likely" a collision will be is the wrong question isn't it?

Passwords collisions are essentially a social and/or psychological phenomenon. Password choice will be influenced by social context and the way our brains are wired.

So unless you have a mathematical model that takes both these factors into account, it's not going to make useful predictions concerning the likelihood of password collisions. I'm not sure how practical it would be to create such a model.

Some other authenticators don't suffer from this problem. E.g. smart cards use machine-generated secrets, so the probability of collision is vanishingly small. So for smartcard authentication, there's no need to ask for a username. Also, I gather the fingerprint reader on the ThinkPad laptops logs you in. (Not tried it - I installed Vista on my T43p as soon as I got it, and the fingerprint reader isn't supported on the Vista betas yet...)

scott lewis said:
> 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.

I suppose the passwords could be generated by the system. This would also mean that the user wouldn't have to think of a unique password...

As stated earlier, if password was the only criteria, you'd frequently have problems where someone could discover another user's password when changing her own. Since you only need a password to login, you've effectively given users a password sniffing device.

You need to look at the psychology of the situation. Most people use passwords like "password". Even forcing them to pick a tough one will get you "pa55w0rd". So accidentally picking someone else's is fairly easy.

What makes me crazy are the password dialogs that require you to double-enter, not the obfuscated password (which is necessary), but your plain-text email. My guess is that the practice catches only a tiny fraction of errors - and it's a nuisance for 100% of users. Bad tradeoff.

As Ian pointed out, the probablilty that two people will choose the same passphrase accidently is greater than you hope. I imagine a large percentage of people would use quotes from pop culture. ("All your base R belong 2 us!", "I coulda been a contender!")

Second, everyone in the system becomes a potential hacker.

Third, just as a passphrase is easy to remember a bad passphrase is easy to guess. If you have a username and that user happens to be ignorant/lazy, you have a reasonably good chance of guessing his password. But what are the odds that out of the entire organization, one person will type "Go Packers" or "All your base R belong 2 us"?

I'm thinking of a passphrase that's over 150 characters long, contains upper- and lower- case letters, numbers, and other characters. I live in the southeastern United States. I bet on that information alone, you or one of your readers will be able to guess my passphrase.

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!

The username adds security.
Its much harder to guess a PAIR of values than it is to guess a single value.

Let's say you had a 1000 users. That means that there are 1000 CORRECT ANSWERS (to a hacker). With a password-only login process, you are 1000 times MORE LIKELY to be able to break in with a brute-force attack.

I like this idea, but I think much more likely would be something that automatically put in our username (based on fingerprint, or proximity sensors, or something else), and we still have to put in the password.

I have to agree with Daniel and Scott Lewis. A passphrase only system would work fine in an environment with 100 users, or even 10,000. But what about Hotmail? You have hundreds of millions of accounts, is it still statistically impossible that a user will choose the same passphrase as someone else?

Users simply will not create random enough passwords, thereby cutting the statistical improbabilities down drastically. If you could force a user to have a 30 character password consisting of "uI987$$%aiAAncca@333ao" that would be secure, but who will remember that without a post-it on their monitor? I'm sure that at least two people would try to use "My dog's name is Jake" as a passphrase.

Okay Now,

That was good out-of-the-box thinking ... but only goes so far as far as practicality is concerned.

I don't think it's gonna work.

As somebody said, there's a trade-off between security and convenience.

The convenience you gain in not having to supply a username, is more than lost when you are required to remember and type in exactly a 30+ character pass-phrase!

May I suggest a better "convenience" workaround ... use auto-suggest in the user name field.

...

...

Accepting your proposed model for a while ...

Picture this... as an Individual, I log in into multiple systems ... my webmail, my PC, my online banking etc etc ... and all these system have their own password (rather, pass-phrase) policies. So it's highly unlikely that you can set the same password for all accounts (Which is not safe anyway), or use a similar punctuation pattern on all of them.

So now I have to remember atleast half-a-dozen 30+ character pass-phrases, which are very likely not plain english.

..

..

And as a hacker if I try typing in just any phrase I like, say, after every coffee break,... there's a good chance I will one day log in into a millionaire's online banking account.

It's almost like your wife sleeping with anyone who spells her maiden name correctly. She doesn't care to look at the face to check if it's you.

Think!

"We broadcast our username in every email we send. There's no security in a username. It's public information."

It's not totally public information. What if someone steals your laptop? They now have to try just passwords. Making them guess a valid username/pass makes it that much harder.

> But what about Hotmail? You have hundreds of millions of accounts, is it still statistically impossible that a user will choose the same passphrase as someone else?

In that specific case (many millions of users), I agree. It's too risky. But it seems safe enough to me for thousands or even hundreds of thousands of users. And that's a much more common case.

> I'm sure that at least two people would try to use "My dog's name is Jake" as a passphrase

As Ian points out, we can't mathematically model this. But I think the actual chance of this happening -- with 30+ character pass-phrases that have numbers and punctuation -- is negligible until you get to the millions of users case.

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. A typical 8 character password, even a highly secure one using most of the ASCII character set, would take 8^90 attacks (1.89e+81) to brute force. That means the pass phrase is 189,344,110,958 times more secure..

I think it's easily secure enough to tolerate a couple hundred thousand users, even factoring in human fallibility. Opening up passwords to complete sentences makes it far easier for users to think up unique, easy to remember secure passwords.

The trend I'm seeing with online banking software is to add more authentication input rather than less.

My ING account requires a customer id, a portion of my SSN, my password, and I have to sing the teapot song while jumping on my right foot to authenticate.

Theoretically speaking, you could require that a passphrase contain your username. That would enhance the uniqueness prospect.

So my password would never be "Who let the dogs out?" but would be "Who let the dogs out Mr. Haacked?"

> use auto-suggest in the user name field.

Finally, some practical advice ;)

> So now I have to remember at least half-a-dozen 30+ character pass-phrases, which are very likely not plain english.

So you use the same exact password on every site you log in to? How is that any better-- once someone discovers your login name, they have access to every system you ever touched!

> if I try typing in just any phrase I like, say, after every coffee break,... there's a good chance I will one day log in into a millionaire's online banking account.

You'd have an equal chance of doing this on any website today. Just pick a common 8 character login name, and an 8 character password. That's only 16 characters, and the list of usernames is typically publically available.. either in email, or user lists. It's far more constrained than the list of possible passwords!

What's the difference between a 16 character password and 8 character username + 8 character password?

And how is a 16 character password easier to hack than a 30+ character pass-phrase?

Users are fallible no matter what password approach we choose. The odds of a user picking an easy to remember 8 character password are just as high as them picking an easy to remember 30 character pass-phrase. The human factor is unchanged in either scenario. The main difference is that we have longer and more complex (yet easier to remember) passwords in the pass-phrase case.

> you could require that a passphrase contain your username. That would enhance the uniqueness prospect.

This is kinda what I was getting at-- a username/password combination is conceptually the same thing as a password that *CONTAINS* your username.

Of course then we're typing our username again, which defeats the original thought question.. ;)

>> 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:

1. ice cream
2. tranquil
3. spider web
4. forensic
5. invent
6. style
7. school bus
8. soul
9. butterfly
10. flag
"

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.

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.

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).

>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.

It just proves there are bad passwords within the 31^70 possibilities. At worst it's a bad example not 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

The whole point of this idea is to replace those 8+8 style authentication systems with ones that allow long passphrases.

> (plus it sucks to type that much blind anyway).

Very true

I don't like "secret questions" on web sites. To me, a secret question is the equivalent of leaving a key under one's door mat. All someone has to do is figure out my mother's maiden name or home town and my account is compromised. It doesn't matter how secure my password is.

Asking Bob for his email address isn't the same as asking a "secret question." Bob knows his passphrase. I also know Bob's passphrase because I stumbled on it. I don't know it belongs to Bob. If there are n users, my chances of guessing to whom the passphrase belongs are 1/(n-1).

Now let's say I ignore the warning and login with Bob's passphrase. When prompted for an email address, I enter Mary's address. I'm not allowed in, Bob's account is locked, my account is locked, and I'm guilty until proven innocent.

What if I actually do guess that the passphrase belongs to Bob? I enter his email address, and I'm in. Now I'm forced change Bob's passphrase before continuing.

The next time Bob tries to log in his passphrase is declined. He calls the helpdesk. The helpdesk sees that Bob's password was reset, and quickly connects the dots. I'm toast.

So yes, in the unlikely event of a passphrase collision there's a 1/(n-1) chance that I could -- if I dared -- get into Bob's account. But remember, I'm not an annonymous hacker. I'm just a lucky stupid opportunist and I'm going to get caught.

You don't have to worry about me. Worry about the genuine hacker who manages to guess Bob's passphrase. If Bob didn't have such a weak passphrase I wouldn't have collided with it in the first place. Hopefully the collision is a lesson to both of us; we'll both choose stronger passphrases.

From what I'm seeing, I'm not seeing any benefit to removing the username from a login prompt. Here's a few reasons:

1. Workarounds are required for accidental collisions.
2. 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.
3. 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.
4. 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.

> I don't like "secret questions" on web sites.

Fair enough. Now that you've described it in more detail, I like the solution you've outlined.

> I'm not seeing any particular benefit in removing the username from the validation process.

The benefit is that it emphasizes the importance of a good pass-phrase instead of a password like "Humongous1"

If users see a single input box in the login dialog, hopefully they'll *think* about it: "Gee, if all someone needs to log in is my password, I better make it unique!"

I believe the traditional user/pass dialog gives people a false sense of security. They think that since a hacker would need their account AND a password to log in as them, they can get away with crappy passwords.

In either case, it's all about the quality of your password. Choosing to drop the username field from the login dialog may be extreme, but it certainly gets the message across.

>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.

Then my distributed attack turns into a denial of service attack. The key point is that you can't figure out what account is being attacked--any reaction you take will disable all accounts.

You're right, Jeff. "It's all about the quality of your password." I think I see where you're going with this now.

If we want a better security system what we really need is to change people's behavior. We need folks to come up with secure passwords and NOT write them on sticky notes.

If you have 100,000 people in your system and drop the username field your system is now 100,000 times less secure. If the story ends there dropping the username is just plain stupid.

But the story doesn't end there. You have to prevent password collisions. In so doing you eliminate the weakest passwords. As Jeff said, maybe having the password stand on its own will make users take security more seriously. Maybe they'll choose more elaborate passwords. Maybe they won't write the password down.

The immediate, obvious effect of dropping the username is your system is less secure. But we must also consider the secondary effects that make the system more secure.

> As Jeff said, maybe having the password stand on its own will make users take security more seriously. Maybe they'll choose more elaborate passwords. Maybe they won't write the password down.

Eg, maybe we can better educate users about pass phrases.

> Then my distributed attack turns into a denial of service attack. The key point is that you can't figure out what account is being attacked--any reaction you take will disable all accounts.

Hmm, no, I think we'd lock your specific IP address out for 2^n seconds. Someone coming in from another IP address wouldn't be locked out.

"Eg, maybe we can better educate users about pass phrases."

Well, yes, but we can do that without elminating the username field.

Crazy talk. The username is useful in text-based scenarios because it provides a method of partitioning the passwords.

The lowest common denominator becomes the worst password, rather than the attacker having to know *who* has the worst password as well.

If you required the user to type something consistent as the first part of their password, you've partitioned the passwords again, and the risk of collisions is reduced (you just sort out the username collisions, and the password is the user's problem), but you're back where you started. They're using a "username" like construct (something required to qualify the rest of the password).

Just guessing a randomly correct password at the console might get a Bad Guy in.

So, you implement a lockout for too many bad attempts, and allow the Bad Guy to deny the system to regular users.

Apply that to IP addresses, and you've partitioned the Bad Guys, but what if a bad guy is behind the same NAT as the good guy?

I don't disagree that the current system has issues, but it's the simplest method out there at the moment with the most reliable result.

Er, there should be an "With no usernames" on the second para! :)

> The lowest common denominator becomes the worst password, rather than the attacker having to know *who* has the worst password as well.

I think that's a design goal here-- no false sense of security from "if the username is required, bad passwords aren't going to hurt us" attitudes. When the only input field is the password, having good passwords becomes mandatory.

> If you required the user to type something consistent as the first part of their password, you've partitioned the passwords again,

Actually, I think Patrick's proposal was to require the user to use at least one unique word of the computer's choosing at the time of password creation. The computer would pick a word that didn't appear in any other password on the domain. This eliminates collisions entirely.

> Just guessing a randomly correct password at the console might get a Bad Guy in.

Yes, but guessing an 8 char username (which is public information) and a 8-12 char password is hardly any easier than guessing a 30+ character passphrase.

> what if a bad guy is behind the same NAT as the good guy?

So then we filter by MAC address, or some other bit of unique information that can penetrate NAT. Or, offer an optional, alternative login screen that does prompt for some other bit of information. We already need this for the password change collision case anyway, so why not re-use it here?

> it's the simplest method out there at the moment with the most reliable result.

I don't think it's simple or particularly reliable; it's a well understood convention that nobody questions very much.

<a href="http://news.bbc.co.uk/go/rss/-/1/hi/business/4340898.stm">http://news.bbc.co.uk/go/rss/-/1/hi/business/4340898.stm</a>;

Something you have, and something you know (as opposed to a username being something you have - it's actually something else you know).

I think most of it boils down to personalization. I know I am Jeremy or jbrayton but who am I when I just type in a password? How do you manage accounts from an Active Directory or simple Control Panel perspective? These accounts have to be named somehow but I suppose the argument is those names simply don't matter in the security process. If they don't matter, why have them in the first place? I think the psychological reasoning of "that is me" makes the current system one everyone will continue to use for a while. It also provides a way for people to feel confident that they know they are logging in as themselves without having to rely on the password for proper feedback.

When it comes to pass phrases I use a program to store all of my passwords. Bruce Schneier originally developed a program called PasswordSafe which is now an open source project. I used that for a long time until I found something better: KeePass Password Safe. I only have to remember one strong pass phrase and I can completely forget every other password I use. Yes that means hackers that somehow managed to snag a copy of the database could get in if they also managed to guess my pass phrase but I'm not particularly worried.

I think the best answer is more along the lines of education for pass phrases (changing names from password to passphrase would help) as well as providing some sort of in-OS tool like OSX has to facilitate storing the sensitive information. This is one application that makes sense at an OS level so that it is more secure (think Isolated storage in the .NET world).

At the end of the day though you can't force people to give up what has worked. I'm actually in awe of how simple the concept and how long it has worked thusfar. The major changes really consisted of simply extending the password to allow for more characters and haven't required a radical revamp since it's inception.

> it's the simplest method out there at the moment with the most reliable result.

> I don't think it's simple or particularly reliable; it's a well understood convention that nobody questions very much.

What is unreliable about it? Having a username with a 30+ character passphrase seems reliable to me. The unreliable factor tends to come from the human side of things that think it's okay to have a password "password" (no quotes).

Usernames weren't so much of a problem before people needed to access multiple accounts. There's something to be said about having multiple accounts to partition things. I may be the administrator of my domain, but I don't dare operate as administrator. I wouldn't want "one account to rule them all" nor would I want to have one "precious" that I must make sure nothing gets corrupted or my "identity" is screwed. I know not having one system that links me to me simply introduces many systems that link me to many "alters". They are all passive systems that I elect to be a part of, not a unique entity that I must protect with my life.

Personally if I have something that important, I hate maintaning it. Something screws up and I have to spend time out of my day making it perfect. A computer account hoses and I create a new one. I'm not on phone with tech support from India trying to explain the urgency of my problem and that it should have been fixed yesterday.

Yes I know I strayed off topic. It's about passwords and usernames but usernames and accounts tie in together. It's important to think of entities and how they tie in. I suppose it was taken for granted that you just have accounts and they have passwords but it wasn't really discussed.

Actually, Jeremy's comment just triggered a memory: We actually had password-driven access controls in Windows 95 (and I'm guessing earlier, but I don't really go back that far).

Win95 had two options for network file sharing: Password-based security, where the password defined your level of access to the target, and user-based security, which required "an NT domain", but accepted an NT workstation as the source anyway :).

Jesper had some comments on the non-user model:
http://blogs.technet.com/jesper_johansson/archive/2005/10/12/412384.aspx

Issuing the first part of a password to the user could eliminate collisions, but that's pretty much the same as a username.

How about: if you're *really* wanting to simulate a non-username based logon, consider the "tab" character to be part of your password, with a fixed initial string? :)

> Issuing the first part of a password to the user could eliminate collisions, but that's pretty much the same as a username.

But it's not.

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 (not just at the beginning or the end). Thus, we ensure password uniqueness across the domain with 100% certainty.

And just to clarify, you'd still have a username. Nothing I've said does away with identity (as the commenter on Jesper's post mistakenly assumed). You just wouldn't need to the username to identify yourself at the login dialog, that's all.

Username/password helps prevent dictionary attacks. How? If someone tries logging in as "daniel", they can keep trying passwords until they guess it. By requiring a password, the system can say, "daniel" can only have 3 wrong guesses, then his account is locked. Well, what if there is no such thing as username? Now you can keep trying passwords until your heart's content; after 3 wrong guesses, whose account do you lock?

So, various people have suggested some mitigation strategies above (such as "just lock out the IP address", or - hah! - "better educate users about pass phrases"). These are unworkable for a host of reasons which the margins of this blog are too small to contain.

However the point remains - why? Just to remove one textbox on the windows login?

> after 3 wrong guesses, whose account do you lock?

I maintain that there's always some uniquely identifiable part of the communication session:

- lock out that IP
- lock out that session/console
- lock out that physical workstation

If all else fails we could temporarily switch to "siege mode" UI where username is again required until the attack subsides.

> Just to remove one textbox on the windows login?

Are you really asking why we should spend extra computer time to make the user's life easier?

> 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 (not just at the beginning or the end). Thus, we ensure password uniqueness across the domain with 100% certainty.

Ah, not 100% certainty.

Scenario 1: You randomly generate a list of words, (keeping a history so you don't duplicate suggestions) and the user must use 1 if those in her password.

User A gets "monkey", and creates the password:
"Monkeys lov3 b@nanas"

User B gets "bananas" and creates the password:
"Monkeys lov3 b@nanas"

There are also some practical considerations about how to ENFORCE the use of one of these words. What if the user "mangles" the word as I've suggested above? Replacing a with @ is obvious, but I'm sure we come up with some much less obvious replacements. Would you have to scan for them all?

Scenario 2: You actually take your list of 12 (proposed) suggestions and examine the current password database to make sure you won't suggest something someone else has already used on their own.

I'm no security expert, but this definitely sounds like a Bad Thing (TM). The way that authentication code works (by design) is a pass/fail, you can't do a "search inside" passwords to see if they contain certain characters.

And if there were, surely there are all sorts of horrible security implication for portions of code that actually do searches or queries on the password list. Could the results be sniffed? Could a query be faked? Could I use low-level APIs to run my own queries as a way to figure out passwords? And as I've asked above, do we have to scan for all possible variations of "ingrate" before we suggest it? 1nGr8? nGreat? iNGrrrate!

That said: most of the comments here are criticizing details of your proposed implementation. I agree with your overlying principle, though, of encouraging (forcing!) users to use longer passphrases instead of passwords. I think we just gotta figure out a better way to actually do it.

Sorry, but this discussion (existence of the username field) IMHO is totally absurd. There are two obvious reasons for having a username;

1) Uniqueness
2) User convenience

From a control point of view, enforcing users to use autogenerated 30 character passwords have the clear risk of the user sharing this password unintentionally. You cannot assume that a user can remember a password or the password cannot be found by any mathematical probability etc.

Every authentication measure (i.e login windows, sso's,laser scanners, biological systems etc) has its own pros and cons and the right one for you can be found out through the productivity/cost ratio, which differs for every scenario.

> enforcing users to use autogenerated 30 character passwords

A pass phrase isn't autogenerated. It's a sentence like structure that the user constructs, eg:

"I live on 369 Colusa Ave. on the 4th floor"
"We have 2 cats: Floyd and Elsie"

Good luck cracking those pass-phrases. An 8 character password of similar strength would look like this:

"7*(x!Z&r"

Which do you think is easier to remember?

We did discuss asking the user to include an arbitrary single word of the server's choosing, in order to ensure password uniqueness-- but nowhere, NOWHERE, did I state that we would force the user to use an autogenerated 30 character password.

So with all this talk about passwords and passphrases the only thing that everyone agrees on regardless of how it gets done is that "passwords" if you will, need to be better, stronger, longer, more complex, etc.

Assume end-users will ALWAYS do the least they have to.

Every password is crackable. The question is how long it takes to crack the password. If you want short passwords, require users to change them every 2 weeks and see how they will like that. I guess they would much rather change a 30-40 character password once every 3 months than a 6-8 character password with non-standard char. every 2-4 weeks.

This is how I approach this problem with my users.

Since when did any end-user have the power to control what the length of their password should be, or trust an end-user to have security on their mind? If this is a work environment and the breech of that password can cause loss of company data it is the job of the administrators of that network to make security a top priority. Users don't get an option, they do what they are told to do. If you don't like it, work somewhere else. To prove that you're serious you check to make sure users are following the procedures. Show up on site and check for post-it notes, make sure users know that you check on them and that there are serious consequences to not complying with the policy, and follow thru with the punishment if there are. If you have IT administrators and CEO's complaining about the security measures they should not be employed by your company or you need to find a company where the executives and IT staff understand. After all they do not have the best interests of the company in mind if they are willing to put their information at risk.

From the standpoint of access to internetbanking sites and personal information it's the users responsibility to have security in mind for their information. If they choose to have a bad password it's their own problem, after all if their own information gets compromised they are the ones that are affected not your company. This will certainly force users to think more about security. Should companies be resposible for doing some educating to their end users, absolutely no doubt about it, but in the end it's under the end users control.

Here is another thought. I understand that this is more of a discussion regarding passwords and passphrases but most hackers need to get past perimiter defenses before having access to the general "users" accounts. These perimiter defenses should be secured with massive complex passwords that are not passphrases, and methods to detect and stop these types of attacks. If a hacker does get past the perimiter you will most likely have more problems than just users passwords.

If you are still worried about passwords getting cracked your only option is to layer the security so if someone wants to hack your systems it takes them so long they would much rather bother the people that haven't changed.

I'm not a security expert by any means, just an administrator who has the companies best interests and security to worry about. This is a simplistic look at something that is far more complex, with the hashing and how passwords are cracked but if the risk is mitigated to the point where the password would be changed before a feasable attempt at cracking it there is not much else you can do with strictly passwords.

"""A pass phrase isn't autogenerated. It's a sentence like structure that the user constructs, eg:

"I live on 369 Colusa Ave. on the 4th floor"
"We have 2 cats: Floyd and Elsie"

Good luck cracking those pass-phrases. An 8 character password of similar strength would look like this:

"7*(x!Z&r"

Which do you think is easier to remember?"""

How are you going to combine that ease of remembering a personal phrase with the inclusion of one or two machine picked word(s)?

"I live on 369 Colusa Ave. on the 4th floor enzyme tornado"

is significantly less memorable. Now it starts to sound like a spam email subject ;)

If there wouldn't be a username and if password would only be required to login, then any person would access any other random person's account by just tyoing the password (only) randomly; and this is what people never expect to happen especially when they have something important in their whatever accounts.

You should try typing foo' 1=1;-- on a poorly written web app and you will get logged in as an admin.

why login at all if it is not necessary, ie on such things as internet shopping? It is the bane of my computer experience. I find what I want on the net, try to buy it and because, five years ago and long forgotten, I bought something else from the site I am asked to log in but not allowed do so as a new customer.

So I look elsewhere! I realise companies want to collect data on customers but is it not self defeating to loose orders in trying to pin customers down?

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.

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.