I find this advice really strange. In all the password-related research studies I’ve read, and in all my conversations with computer users, I don’t think I’ve once heard someone complain that they are worried about typos in their password. People will complain at length about forgetting what their password is in the first place, and this is why most choose overly-simple passwords, or just write them down.

It seems like Nielsen has invented a problem where none exists. Nonetheless, he recommends that websites stop masking users’ passwords as they are entered. This whole viewpoint is wrong for a number of reasons:

1. Nielsen claims that password masking is only done today because “it was the default in the Web’s early days”. In fact, it has been the default as long as computers have used passwords as an authentication mechanism. And it’s the default for a good reason: it complicates shoulder-surfing attacks with a minimal impact on usability.
2. He also argues that displaying passwords in plaintext will increase a user’s confidence, leading to increased security because the user will choose a longer password. However, in a past article, Nielsen also claimed it is a lie that “long passwords are more secure than short ones”, and declared unequivocally that “users write down their passwords”. You can’t have it both ways, Jakob.
3. For a log-in form to display the password in the clear is not the expected system behavior, and this is bad for usability. Nielsen suggests that a site could provide a check-box to enable password masking. Having to click a button to get the desired default behavior is also terrible for usability.

Perhaps the most egregious error in all the article is this gem:

More importantly, there’s usually nobody looking over your shoulder when you log in to a website. It’s just you, sitting all alone in your office, suffering reduced usability to protect against a non-issue.

In the real world, people work in open offices, log-in to websites during presentations, browse the web with their significant-others, and expect websites to respect their privacy. But I will concede that in Jakob Nielsen’s private office, on the penthouse floor of his ivory tower, password masking is probably useless.

If an attacker can try just a single password against every user on your web application, he’ll compromise about 1% of them. Even with a fairly stringent 3-attempt lockout policy, about 2-3% of your users will be compromised.

More complex password requirements aren’t the answer here; many of the most popular passwords are at least 7 characters, and have 1 or more digits. Disallowing any passwords appearing on one of these lists would alleviate the issue, but seems like a pretty shoddy user-experience.

There is one way to prevent this site-wide brute force attack: do not give away a list of log-in usernames for your site! This attack only works if the attacker can enumerate all logins to your web app. This is an easy task for many sites, like Digg, where usernames are publicly plastered all over the site. Sites like Mint on the other hand, which use e-mail addresses for log-in, are immune.

The key point is that you should never reveal whether a particular e-mail/username is registered with your site. That means your “log-in failed” page should not indicate whether or not the username was correct, for example. If there is any way to determine if a given username is registered, an attacker can leverage that to pull off a site-wide brute force.

So, is your site enabling brute-force attacks? If so, now is the time to go change your architecture to stop this attack in its tracks.

Haddock-generated passwords are of the form {word}{number}{symbol}{word}, and are generated to be at-most as long as a user-specified length. So for example, an 8-character Haddock password might be “amy7@rax”.

For a relatively low-security password, like you might use for your Twitter account, this is probably fine. It is certainly easier to remember than a password chosen uniformly at random from the available password-space, but does this memorability comes at a cost?

Haddock uses the UNIX /usr/share/dict/words file, which as about 480,000 words total. If I ask Haddock for an 8 character password, I’m likely to get something with 2 3-character words, a single digit, and a single symbol. There are about 6,200 3-character words in the dict file, and Haddock uses 10 digits and 35 symbols. Therefore there are about 6200 * 10 * 35 * 6200 = 13,454,000,000 possible 8-character passwords that Haddock can generate.

Although this is several orders of magnitude less than a uniformly-random password, it seems to make an acceptable trade-off between security and ease-of-use for non-critical account passwords.