Bad password policies

Thu 21 June 2012
InfoSec

Ever since I got my Yubikey I've been a big fan of making sure my many web application accounts are as secure as possible. Thanks to services like LastPass you can now keep up unique complex passwords on every account you own with very little extra effort.

So, in this spirit I decided to change my "My 3" account password at Three.co.uk. I fire up the random password generator and create a nice large random string. I take the string and feed it into their change password dialogue only to be told that only passwords less than 12 characters will be allowed. This backwards thinking is common is a lot of web applications, usually because of very bad design decisions made by the developer when it came to managing user authentication. A lot of times it is the indicator that passwords are stored without hashing.

On small web apps you should probably note this and make sure that you don't use them if you value your security, however this app was one that I had to use and this password policy and it's worrying implications were holding my mobile phone records so I was not going to let this go. I sent the following tweet to @threeuksupport yesterday:

#fail@ThreeUK@ThreeUKSupport "Your new password can not be greater than 12 characters in length"

Very soon they got back to me and a number of my followers that also happened to be customers saying that they would pass this to the security team and get a response back. This is actually pretty unusual for companies like this, as they mostly like brushing things like this under the carpet.

This morning the few of us that raised this got an email response from Three, Included below in the email they sent and my in-line reply.

On 21 June 2012 11:37, socialmediacare <SocialMediaCare@three.co.uk> wrote:

.. raw:: html

Hi there, .. raw:: html

.. raw:: html

Following the discussions on Twitter regarding My3 passwords, I've spoken with our security team and they've advised of the following: .. raw:: html

.. raw:: html

- Passwords obviously need to be stored in a database. .. raw:: html

.. raw:: html

No, passwords should *never* be stored. They should be salted with a unique value per user and hashed with a computationally expensive algorithm.

.. raw:: html

To prevent threats from things like SQL Injection, it is necessary to limit the password length so that Hackers cannot enter lengthy SQL statements (as passwords) to try and retrieve data from the database, corrupt it, or use Cross Site Scripting techniques by entering Javascript etc in input fields. .. raw:: html

.. raw:: html

SQL Injection and XSS are defeated by proper input and output validation, not restricting the length of users passwords. This is a basic premise of securing web applications.

.. raw:: html

- Most people find passwords hard to remember. This is compounded when the password policy mandates that it must contain a combination of letters and numbers. .. raw:: html

.. raw:: html

Does this mean that you *don't* mandate alpha-numeric passwords?

.. raw:: html

To help ensure passwords are more memorable, and to reduce calls into the contact centre relating to forgotten passwords and locked accounts, the policy has been set such that a minimum of 7 & maximum of 12 characters is supported. .. raw:: html

.. raw:: html

How does stopping a user from using a 13 character password prevent the user from forgetting it? At least you can admit that your goal with this policy is to reduce customer support calls. This is easily mitigated by having a robust automated password re-set mechanism as used on thousands of other web applications. Small sites like ebay and paypal.

.. raw:: html

Passwords longer than 12 characters are no more ‘secure’ but are significantly more likely to not be remembered or miss typed. .. raw:: html

.. raw:: html

Forgotten an mis-typed yes, "less secure" You could not be more wrong. Please tell me how you arrived at the conclusion that passwords length does not impact on the security of the users account

.. raw:: html

Password security is largely a factor of the user’s choice of password. Something that is memorable to the user will always have the potential to be ‘guessed’ by another person through possible social engineering techniques etc. .. raw:: html

.. raw:: html

If a password is longer than 12 characters, a user is more likely to have to write it down somewhere. .. raw:: html

.. raw:: html

So you are arguing that a long password would be written down, therefore only exposed to a local physical security breach, so we'll make sure they *can't* have a long password and then they'll only be exposed to every phishing site, keylogger and brute forcer on the planet? How does that make any sense? You position acknowledges that short memorable passwords are insecure (something you denied in a previous paragraph) yet you decide that the best position for you is to mandate them?

.. raw:: html

- It could be argued that 12 characters is a little restrictive. However, the reference to the recent Linked-in miss management of passwords, some might say is an irrelevance in relation to limiting the maximum password length to 12 characters. On this note, non of the passwords are stored in clear text form. .. raw:: html

.. raw:: html

You need to look at the Linkedin breach and answer this again. At least Linkedin hashed their passwords, but without a salt and a CPU expensive algorithm the passwords were recovered for the vast majority within a few hours. First to fall were the dictionary words, so tell me again why you are limiting used to small passwords that are easy to remember?

.. raw:: html

While we obviously have a duty of care over customer data, but we also have to find the balance between protecting this data and usability. .. raw:: html

.. raw:: html

You do have a duty of care over customer data, I'm glad that you realise that. With the recent exposure of phone infrastructure hacking from NI and other journalists I would have hoped that you realised that you hold the very private and personal data of a vast number of individuals who expect you to at least abide by industry best practice when it comes to securing access to it. If I were a high profile individual then this response from a national mobile infrastructure company then I would be very concerned about people who wish me harm gaining access to my call records.

.. raw:: html

Thanks for raising your concerns with us. .. raw:: html

.. raw:: html

I look forward to seeing you'r acknowledgement of these issues and remidating them as soon as possible.

P.S I'll be asking about your username policy next.

So there we have it. I'll wait patiently for a reply from Three and let you know the outcome.

UPDATE

Here is the reply from Three UK

Hi Ian

I've raised your further email with our security team. They've advised that they're unable to enter into further discussion with you regarding our technical details on how wwe manage and store user credentials.

In doing so, would only be a security risk in itself.

Our website clearly states "Your password must be at least 7 characters long and must contain at least one number and one letter" and we do enforce these contraints.

Please take this as our final response on the matter. I hope you understand the reasons why we're unable to go in to any further security specifics with yourself.

Thanks

So there we have it, I shouldn't worry my pretty little head about it and we if we told you what we actually do to secure your data the entire planet would explode. Draw your own conclusions.

I guess I shouldn't worry that they've got a new interface to My 3 in beta accessible to all users going on right now. I bet that thing is tight as drum.

FishermansEnemy

Musings of an infosec nerd

Bad password policies

UPDATE

About