Forgot your password?
typodupeerror
User Journal

0x0d0a's Journal: Fixing the Login Screen 7

Journal by 0x0d0a

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.

This discussion has been archived. No new comments can be posted.

Fixing the Login Screen

Comments Filter:
  • Mostly I'm thinking GUI environment here, but some of this could apply to text based stuff:

    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
    • 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 correct username.

      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
  • I never liked systems that echo anything for passwords. It doesn't provide much good feedback, if I make an insertion/deletion typo I may spot it. But really you're not going to be counting to see if you've got 7 or 8 asterisks when you're quickly trying to login (or care for that matter-- go ahead, get it wrong, then wait a couple seconds & try again). And echoing asterisks can only give someone else a count of how many characters are in your password.

    I've never given much thought to the login id f
  • ...is that we're running out of passwords.

    Not in the sense that there aren't any more, but in the sense that the set of passwords that

    • A normal user can reasonably be expected to remember without writing down
    • and that are sufficiently hard to crack

    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

    • and that are sufficiently hard to crack

      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
      • You can do trickery, sure. But it only brings you so far.

        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:

        • Something they know. (i.e. a password)
        • Something they have (i.e. a smartcard or a key)
        • Something they are (i.e. biometrics, or just plainly being *recognised* by the guard at the build
        • But it only brings you so far.

          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.

: is not an identifier

Working...