Chris Kite Programming, Computer Security, Etc.

Jakob Nielsen today wrote an article calling for all log-in forms to display passwords in plaintext, rather than masking them with bullets or stars. He argues that this increases usability (users feel more confident because they can see their password as they type it), and also increases security (a more confident user will choose stronger passwords!).

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.

For the longest time, I’ve wanted Firefox to put the “Open Link in New Tab” option at the top of the context menu when I click on a link. I use this option all the time, and the mild annoyance of having to move my mouse to get to it has added up over the years. I even switched to using Google Chrome as my main browser partly because it has the “Open in New Tab” menu item right where I like it: at the top of the right-click context menu.

Today I was finally about to write a Firefox extension just to correct this annoyance when I stumbled upon the Firefox Menu Editor extension. This add-on allows you to edit the text and position of pretty much any menu item in Firefox 2 and 3, including the one I care about most! I installed it, tweaked the menu, and now I’m a happy Firefox user again.

With more and more web sites and businesses embracing Twitter, it’s important to make it as easy as possible users to share content on the social networking site. That’s why I just coded up a jQuery plugin called TweetLink, which allows web developers to easily add “Tweet This Page” buttons to their site.

After the TweetLink plugin is included, when any DOM element with class=”tweetlink” is clicked, the current page’s URL is automatically shortened using bit.ly. The user is then automatically forwarded to Twitter, where their status box is already filled in with the page’s title and the shortened URL.

This plugin should make it painless for web developers to include this functionality, and easy for visitors to Tweet interesting content.

Download TweetLink at the jQuery project page, or browse the code at GitHub.

Twitter has had a lot of embarrassing security problems in the past, but the worst part is that they still haven’t learned from their mistakes. Apparently a recent redesign left the profile page vulnerable to a very simple XSS attack.

Some enterprising hacker quickly seized the opportunity to promote Twitter-clone StalkDaily by infecting the profiles of hundreds of users, and using their accounts to Tweet marketing messages such as “Join www.StalkDaily.com everyone!”. StalkDaily denies any responsibility for the XSS attack. The source-code for the worm is available, and reveals just how simple this attack really was.

Here is a little free advice for the developers at Twitter: install xss-shield, or start using h() to escape user-supplied strings in your templates. Since the field that was vulnerable to cross-site scripting and allowed this worm to propogate was supposed to be a URL, it might not hurt to validate that against a simple regular expression while you’re at it.

I’ve lost count of the number of security breaches Twitter has had in the past few months. The question now is whether they’ll hire a competent web security architect and clean-up their act.

I came across a really useful Ruby gem today: andand. In PHP web development, I usually use this idiom when retrieving an object from the database model:

$obj = $model->getObject($id);
if(null !== $obj) {
    doSomething($obj);
}

Obviously this is a little cumbersome, since I have to do this every single time I get an object using a function that might return null. Reginald Braithwaite, author of andand, has made this process a heck of a lot easier for all the Rubyists out there. His gem allows natural method chaining for functions that can return nil:

@phone = Location.find(:first, ...elided... ).andand.phone

This saves a lot of boilerplate code and improves readability. I like it.

In his latest blog post, Andy Sloane issued a challenge to create a key-generator for his bespoke software licensing scheme.

Looking through his code, I quickly found that he was using RSA, and that valid keys decrypted to 12345678 under a hardcoded RSA public key.

In my response on the Reddit discussion, I explained creating a keygen was as simple as adding a multiple of his public-key modulus n to an existing key. Others quickly pointed out that it was trivial to factor n because it was not sufficiently large.

This is a great example of why creating secure systems is so hard: implementation mistakes are easy to make, and undermine the security of even the best cryptosystems.

Jimmy Ruska has taken the time to combine data from 3 compromised-password lists, and the results are pretty interesting.

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.

Newly released RubyGem Haddock offers to generate easy-to-remember passwords, but how secure are they?

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.