Home / Blogs

Password Policies Need to Be the Same if We Want Users to Take Our Advice

Terry Zink

The other day on Facebook, one of my friends mentioned that today (i.e., that day) was a good day to update his passwords. But he then lamented that some web sites don't allow you to create more than a 12-character password! He was incensed! Well, maybe not incensed but showed contempt for the fact these sites restricted password length.

As any good security person will tell you, the longer a password is the more secure it is (of course, the fewer failures a web site permits, the more resistant a website is to brute force attacks). But this annoys me about the industry — we preach that users need strong passwords (by recommending that they use different ones across all or most of their web logins that are impossibly long and oh, yeah — don't write them down because we're all so good at remembering long strings of random numbers and letters) and yet we can't even co-ordinate our security policies.

  • Some web sites allow you to have more 12 characters, others don't.
  • Some web sites allow you to use special characters like ^, &, /, !, %, and so forth, and others don't.
  • Some web sites allow you to fail three times before locking your account for an hour, and others don't.
  • Some web sites allow you to specify a password in all lower case, and others don't.
  • Some web sites will tell you if your password is secure, and others don't.
  • And on it goes.

I can see why some web sites would restrict the use of special characters — it's to resist SQL injection attacks or similar. But aren't there other ways to sanitize the input without restricting users' abilities to keep themselves secure?

And what's up with restricting the number of characters to less than 12? Is it to save on hard disk space? Seriously. If your capacity is in trouble because of hardware disk space, you've got other problems. If you are trying to reduce cross site scripting or SQL injection attacks, find another way to sanitize the input.

Before we continue to complain about the irresponsibility of users, the security industry needs to clean up its own act and stop making things so difficult for users to understand and use in real life. The security industry has to get smarter about the ways it transmits its messages. Make it easy for users to be secure so they have to earn the loss of their data.

By Terry Zink, Program Manager
Follow CircleID on
Related topics: Cybersecurity
SHARE THIS POST

If you are pressed for time ...

... this is for you. More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Vinton Cerf, Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Share your comments

SOP The Famous Brett Watson  –  May 03, 2011 1:59 AM PST

But aren't there other ways to sanitize the input without restricting users' abilities to keep themselves secure?

Restricting characters in input is completely the wrong way to go about it. Any half-decent database API has facilities for automatically quoting and un-quoting SQL strings. It's a sad indictment on the industry as a whole that SQL injection attacks exist at all.

And what's up with restricting the number of characters to less than 12? Is it to save on hard disk space?

Usually it's because someone, at some point in time, arbitrarily decided that the password field should be of type "char(n)" for some value of n. The person who designed the database schema--using the term "design" loosely, since actual deliberation is rare--probably wasn't a security expert, and n characters was enough for his password.

A small portion of today's quick and dirty hacks go on to be tomorrow's core systems, along with their hard-to-fix-in-retrospect lack of security planning.

To post comments, please login or create an account.

Related

Topics

Cybersecurity

Sponsored byVerisign

DNS Security

Sponsored byAfilias

New TLDs

Sponsored byAfilias

Cybercrime

Sponsored byThreat Intelligence Platform

Whois

Sponsored byWhoisXML API

IP Addressing

Sponsored byAvenue4 LLC

Domain Names

Sponsored byVerisign