Why Do Login Dialogs Have a "User" Field?

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.

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.

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

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.

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

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

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.

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!Zr”

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.

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.

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!Zr”

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

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?