Security

How does bad password policy like this even happen?

Just when you think you've seen the worst case of bad authentication policy you'll ever see, you'll stumble across something even more surprising and unfathomable.

Nelnet, for those who aren't aware, is the "National Education Loan Network". These are guys who manage student loans — which means they manage information related to people's educational history and loan status. The Website takes credit card numbers for automated payments, for an example of the sort of sensitive information Nelnet handles online.

Imagine my surprise when I saw this on a page at the Nelnet Website:

Nelnet Password Requirements (cropped)

In case you can't view the image, cropped from a screenshot, the following is a quote of the above list of the requirements for passwords at Nelnet:

  • It is case sensitive
  • It can't contain special characters (?&%$#@+=!'~, etc.)
  • It can't contain your user name
  • It can't contain two separated numbers (i.e., Abc12ef34 would be invalid)
  • It can't contain "Nelnet" or "Password"

I mentioned some choice parts of that list of restrictions on passwords to fellow TechRepublic Weblogger Sterling Camden (who writes for the IT Consultant Weblog). In the ensuing discussion, he said "I've seen some sites that don't allow more than 6 characters for a password, no numbers or special characters." As he put it, some Web developers are "too paranoid of SQL-injection to even know how it works". The easy lesson to take from this is that, knowing in a vague sense something about a particular threat to security without actually understanding it, one might make the mistake of artificially limiting users to only very weak passwords — thus reducing effective security overall.

As I observed, in that same discussion, I can almost understand how some sites end up restricting passwords to short strings of alphanumeric passwords, or possibly even just alphabetic characters — and possibly without case sensitivity. A very poor developer may just not know how to write code that can handle case sensitive code that contains more than alphanumeric characters in a given development environment. I'm not saying that there's anything good about it, but at least I can understand how it might happen.

What I don't understand is how that fourth restriction on passwords at Nelnet, "It can't contain two separated numbers", happened. What kind of bizarre kludge of code on the back end would result in someone deciding it's too difficult or dangerous to parse numbers separated by letters in a password? Is there some code in there that actually attaches numbers to the edges of a password string? Is that restriction a very simpleminded (and prone to failure) attempt to "force" people to do something cleverer than 1337speak? I'm really having a difficult time coming up with an explanation for how this happened that is even remotely believable. Am I overlooking something obvious?

After I ranted briefly at him about how bizarre the back-end code for password validation at Nelnet must be, Sterling said "I bet the validation code for that one is a candidate for the DailyWTF." I'd bet he's right.

Oh, but wait — it gets better. See, this absurd state of affairs is an improvement over previous conditions at Nelnet. Not long ago, users didn't choose usernames at Nelnet. No, they had to use their Social Security Numbers as user IDs. For those of you who are not entirely clear on the concept, user IDs should never be sensitive information — and, though banks, schools, and every other large institution in the world seems to want to demand your SSN every few minutes, it really should be treated as sensitive information. It can be used to commit identity fraud very easily.

Think about the fact that all these places demanding your SSN for identity validation leads to it being trivial for someone to impersonate you. The kind of people who would commit identity fraud can target one place where it's easy to acquire your SSN, then use it somewhere else to get access to something they shouldn't be able to access.

Productivity is not about speed. It's about velocity. You can be fast, but if you're going in the wrong direction, you're not helping anyone.

Those are the words of Phillip J. Haack, and they seem relevant. I guess the fact Nelnet no longer uses SSNs as login IDs means things are moving in the right direction. They just aren't moving fast enough. That's at least better than moving very quickly in the wrong direction.

I just hope Nelnet doesn't do all its password validation with JavaScript on the client.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

Editor's Picks