Terry Zink's Cyber Security Blog

Discussing Internet security in (mostly) plain English

Password policies need to be the same if we want users to take our advice

Password policies need to be the same if we want users to take our advice

  • Comments 2

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 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.

Leave a Comment
  • Please add 8 and 6 and type the answer here:
  • Post
  • When I see sites which restrict certain attributes of passwords, I assume that these sites are not properly hashing the passwords. Storing hashed passwords (and throwing away the plaintext) means that you don't have to store the password in your database or on your disk so the character set or length doesn't matter. If you run the input through your hasher then SQL injection attacks are moot because by the time SQL sees your string, it's already hashed.

    (You can also do something like hash the string on the client-side, transmit the hash, and then salt + hash it a second time on the server side. This means that your server never even *sees* the password, if you're uber-paranoid about accepting user input).

  • If I were to run a website were a password would merely be something for users' convenience (e.g. a forum where people chat about not-too-important stuff) I would seriously consider enforcing a not-too-strict password policy to ensure these people would use different passwords for Paypal/webmail etc.

    Mailman kind of does that: it doesn't enforce anything but it warns you that it stores passwords unhashed (so that it can be emailed to you) and urges you to use something insecure.

Page 1 of 1 (2 items)