Journal 0x0d0a's Journal: Fixing the Login Screen 7
As mentioned here, one security problem with passwords is accidently typing one's password into the username field when logging into a system. This can be a problem if the password is being entered in an environment where other people are watching the screen.
Generally, the password field is "masked" in password entry systems to prevent people from reading the entered password -- a character count may be shown with asterisks (as on the Windows login screen or in Red Hat's gdm), visual feedback may be provided as each character is entered (as on the Lotus Notes login screen), or no feedback at all (as on Red Hat's terminal login screen).
It seems that the "accidental password entry in username field" problem could be avoided by also masking the username field.
There would be some issues with such a scheme.
First, it increases the number of characters that must be blindly typed correctly to reach a login. I do not feel that this is likely to be a significant issue, as users type their usernames on a regular basis into the machine.
Second, it eliminates visual feedback that would tell a user that they have the caps-lock key down, a common problem when entering a password.
Third, it prevents people from troubleshooting issues with keyboard configuration (for example, the keyboard may not have the correct layout selected).
I feel that the caps lock problem may be solved in several ways. First, it is possible for many systems to put a visual warning indicator onscreen when the caps lock is on. This may be a good idea, as it is almost never desireable to have caps lock enabled when entering username and password. However, not all systems can detect the state of the caps lock (for instance, when telnetting into a remote machine, caps lock state is not sent to the machine -- breaking this approach when dealing with a remotely-generated password dialog).
Second, it might be possible to print a warning if a username is entered in all capitals.
Third, it might be possible to toggle the masked nature of the username field (possibly through an out-of-band mechanism such as a mouse), or possibly by simply entering a zero-length password and username, or hitting a key on the keyboard that is not reserved for password entry. This way, the vast majority of the time, the username field would be masked, and only unmasked if someone is troubleshooting login problems.
OK... I'll bite... (Score:2)
The problem of the username field *could* be fixed in a similar way to the "password question" that many login systems use to recover a user's forgotten password. When the account is being created (assuming the user creates it), or perhaps as a first time login procedure, the user would be prompted for a "username verification word". They could then pick a word or phrase that would display only if they entered the
Re:OK... I'll bite... (Score:2)
I can think of two potential issues to deal with here.
First, many systems treat the existence of a username as somewhat sensitive information, which is why most systems do not immediately print "invalid username" when an invalid username
how about not echoing either field? (Score:2)
I've never given much thought to the login id f
A more fundamental problem... (Score:2)
Not in the sense that there aren't any more, but in the sense that the set of passwords that
is getting smaller and smaller.
This is so because the first, what a user can reasonably be expected to remember, stays more or less constant, while the brute force available to an attacker rises all the time. Also, the length of the typical password-list ris
Re:A more fundamental problem... (Score:2)
Most passwords today could probably not withstand a good crack run.
However, I do not believe that there are still any *IX variants that ship without shadowed password support on by default, so users generally cannot (easily) run crack.
Today, password strength is more useful to avoid brute-force login attacks on systems that do not protect well against such attacks.
It's not impossible to just increase the cost of the computation involved. Suppose, for instance, th
Re:A more fundamental problem... (Score:2)
What I think is more promising is a shift from passwords-only authentication to passwords-and-token authentication.
Let's step back two steps and look at identification more closely. Principally, when you want to identify someone, there's 3 different ways used today:
Re:A more fundamental problem... (Score:2)
Mmm...I don't think I can agree. I think that you can go arbitrarily far using such a technique. Of course, you'll always have to worry about upgrading your hash every ten years or so to keep within the "usefulness"/"secure" window.
On the other hand, I agree absolutely with you that smartcard/PIN keyring systems are almost always preferable, if you can convince people to use them. I'd use such starting this moment if systems supported them.