Skip navigation

Thinking about passwords

A recent debate erupted in the security community about the utility of password masking. Password masking is the process by which a password is displayed as a series of non representative characters, such as ******** when you enter the password.

The argument was made that in the vast majority of circumstances password masking is not necessary because there is no-one standing behind us when we enter our passwords. If there was someone standing behind us, we could just wait until they left to before we entered our password. In the event that we were unaware of someone standing behind us, only someone with a photographic memory could remember that password if they saw it displayed on the screen for the amount of time it takes to enter the password. Of course such a person could probably work out and remember a password by viewing us typing it on the keyboard anyway, so if you are dealing with someone who is determined to learn your password but who has a photographic memory, you are out of luck.

So the basic argument was that password masking is not a very effective means of security, though there were caveats for things like cameras (which again could be pointed at keyboards as well as screens).

The next point was that this form of security that was perhaps not fully effective was causing organizations a lot of money because when passwords were masked people were more likely to make mistakes entering them. This would lead to account lockouts which required direct intervention from someone in the IT department to resolve the issue.

Password masking is not something that you can directly enable or disable in current versions of Windows, so there is no easy practical solution to this problem. One solution proposed is to disable account lockout policies or set them to a high number. Windows can be configured to an account lockout threshold of up to 999 invalid attempts. Rather than locking users out after 3 or five invalid attempts, if your concern is someone trying some sort of automated attack, you can choose a number like 50 invalid attempts. There are few users who will fail when entering their password 50 times before calling IT support and the users who may have been locked out after 3 invalid attempts might have correctly remembered after a few more.

Another solution that has been proposed is to get people to write down their passwords and keep them in their wallet. The theory goes that people are good at keeping things in their wallet, like their credit card, secret and they are probably more worried about someone learning their credit card number than they are with someone learning their password.

Our current approach to passwords has a lot of inertia. The main question raised by this debate is whether the current approach is the best approach to dealing with the problems that passwords are supposed to solve. Making users rotate their passwords frequently does ensure that if someone discovers a user’s password, that the password only remains compromised for a certain amount of time. An important question is, in organizations where user security is not critical, does this solve more problems than it causes. Administrators should have rigorous password policies applied to their accounts, yet interestingly enough administrators are one of the first people to configure the password never expires setting on their own account whilst merrily forcing less privileged users to constantly rotate their passwords.

Perhaps with Project Natal’s people recognition technology on the horizon we might be able to move beyond passwords. Any attacker who is sophisticated enough to get around person and voice recognition that is available in Natal will not have much in the way of problems getting around an old fashioned username and password combination.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish