isnoop.net blog

As a follow-up to my last post, here are a few tips to help keep you from driving your site users away with misguided password restrictions.

#1: Consider Context

Your tweets may be precious to you, but as a web developer, you should understand the differences between password security for Twitter and for online banking. Consider the monetary and legal damages that to both you and your customers if their account were compromised and plan accordingly.

#2: Character Taboos

Since you are properly protecting passwords by only storing a hash, there is no reason to limit characters they use in their passwords. Don’t tell your users they can’t use symbols or start their password with a space if that’s what they want to do. In the end, all you’ll be storing is an alphanumeric hash of the password anyway, so it shouldn’t matter if they send you a bunch of binary gook.

#3: Password Rotation

Set reasonable requirements for password rotation. If yours is a high-security system, it is reasonable to require password rotation every few months. In order to prevent abuse, it is even reasonable to check for duplicates against the last N password hashes or all of the hashes used the last few months. Before implementing any password rotation scheme, be sure you’ve visited and revisited #1 above.

Despite the practices of some sites, there is rarely if ever a good reason to keep an unlimited log of every password a person has used, never letting them be reused.

#4: Minimum password lengths

Let’s assume someone really wants into one of your user’s accounts. If they had the capabilities of attempting a blistering 1,000 different passwords per second, here’s how long it would take to try every possible combination:

The exponential growth of possible combinations makes password cracking infeasible pretty quickly. Assuming 1,000 attempts per second is ludicrous against a webserver, but assuming your database isn’t compromised, this should be the only means an attacker can brute force an account. The time to compute reaches absolute absurdity after just 8 lowercase characters.

#5: Maximum Password Lengths

As in character taboos, what do you care if your users have 100 character long passwords? It is reasonable to put a ceiling on password lengths to prevent blatant abuse (perhaps in the neighborhood of 500-1,000 chars), but don’t limit your users to a 12 character password because that’s all your schema can hold.

Remember that you should be hashing passwords and that most hashes produce a fixed-length output no matter the input.

Just a quick note to any developer, site owner, or project manager who is in charge of developing a user login system:

Don’t put unreasonable restrictions on usernames.

It is sensible to prevent people from creating names containing certain characters or names of extreme length. However, some sites go too far by requiring all user names be 7-12 characters in length. Other sites forbid user names that begin with numbers.

A more reasonable approach would be to allow user names from 3 to 16 characters, with a limited set of punctuation allowed, and the first letter cannot be whitespace.

Remember that user names are generally public information so you don’t need to apply the same protections you do to ensure strong passwords. Do the right thing and your users will thank you by not abandoning your account creation form.

They say clothes make the man, so it stands to reason that the theme makes the blog. After receiving several moans about my blog’s styling, I’ve finally decided to do something about it. No more Kubrik theme for me.

For those who don’t care for the WordPress default theme, I do hope this one is more appealing. For tech and convenience oriented folk like myself, this new theme was easily customizable to support multiple widget bars. Plus, I hear three column fixed width layout is in this year.