Mastodon

Banks, Arbitrary Password Restrictions and Why They Don't Matter

18 September 2019

Allow me to be controversial for a moment: arbitrary password restrictions on banks such as short max lengths and disallowed characters don't matter. Also, allow me to argue with myself for a moment: banks shouldn't have these restrictions in place anyway.

I want to put forward cases for both arguments here because seeing both sides is important. I want to help shed some light on why this practice happens and argue pragmatically both for and against. But firstly, let's just establish what's happening:

People are Upset About Arbitrary Restrictions

This is actually one of those long-in-draft blog posts I finally decided to finish after seeing this tweet earlier on in the week:

It feels wrong because 5 digits presents an extremely limited set of different possible combinations the password can be. (There's something a little off with the maths here though - 5 digits would only provide 100k permutations whereas 5 characters would provide more in the order of 1.5B.)

That said, Westpac down in Australia certainly appears to be 6 characters:

Which puts us well north of a billion possibilities again. Want more? CommBank will give you 16 characters:

On the one hand, it's a damn sight more generous than the previous two banks yet on the other hand, why? And while I'm here questioning CommBank's logic, what the hell is going on with this:

1Password has an open letter to banks on precisely this because its awful advice steeped in legacy misunderstandings of both technology and human brains. That open letter is often used as a reference to persuade banks to lift their game:

So on the surface of it, the whole thing looks like a bit of a mess. But it's not necessarily that bad, and here's why:

Password Limits on Banks Don't Matter

That very first tweet touched on the first reason why it doesn't matter: banks aggressively lock out accounts being brute forced. They have to because there's money at stake and once you have a financial motivator, the value of an account takeover goes up and consequently, so does the incentive to have a red hot go at it. Yes, a 5-digit PIN only gives you 100k attempts, but you're only allowed two mistakes. Arguably you could whittle that 100k "possibilities" down to a much smaller number of "likely" passwords either by recognising common patterns or finding previously used passwords by the intended victim, but as an attacker you're going to get very few bites at that cherry:

Next up is the need to know the target's username. Banks typically use customer registration numbers as opposed to user-chosen usernames or email addresses so there goes the value in credential stuffing lists. That's not to say there aren't ways of discovering someone's banking username, but it's a significantly higher barrier to entry than the typical "spray and pray" account takeover attempts.

Then there's the authentication process itself and it reminds me of a discussion I had with a bank's CISO during a recent workshop. I'd just spent two days with his dev team hacking themselves first and I raised the bollocking they were getting on social media due to a new password policy along the lines of those in the tweets you see above. He turned to me and said, "Do you really think the only thing the bank does to log people on is to check the username and password?" Banks are way more sophisticated than this and it goes well beyond merely string-matching credentials; there's all sorts of other environment, behavioural and heuristic patterns used to establish legitimacy. You won't ever see a bank telling you how they do it, but those "hidden security features" make a significant contribution to the bank's security posture:

Then there's the increasing propensity for banks to implement additional verification processes at key stages of managing your money. For example, one of the banks I regularly use sends me a challenge via SMS whenever setting up a new payee. Obviously, SMS has its own challenges, but what we're talking about now is not just needing to successfully authenticate to the bank, but also to prove control of a phone number at a key stage and that will always be more secure than authentication alone.

And if all of this fails? Banks like ING will give you your money back:

Now, compare all this to logging on to catforum.com:

How much sophistication do you think is behind those username and password fields in that vBulletin forum? Exactly, it's basic string-matching and this is really the point: judging banks by the same measures we judge basic authentication schemes is an apples and oranges comparison.

However, I disagree with banks taking this approach so let me now go and argue from the other side of the fence.

Banks Shouldn't Impose Password Limits

There are very few independent means by which we can assess a website's security posture in a non-invasive fashion. We can look for the padlock and the presence of HTTPS (which is increasingly ubiquitous anyway) and we look at the way in which they allow you to create and use passwords. There are few remaining measures of substance we can observe without starting to poke away at things.

So what opinion do you think people will form when they see arbitrary complexity rules or short limits? Not a very positive one and there are the inevitable conclusions drawn:

Hey [bank], does that 16 character limit mean you've got a varchar(16) column somewhere and you're storing passwords as plain text?

As much as I don't believe that's the case in any modern bank of significance, it's definitely not a good look. Inevitably the root cause in situations like this is "legacy" - there's some great hulking back-end banking solution the modern front-end needs to play nice with and the decisions of yesteryear are bubbling up to the surface. It's a reason, granted, but it's not a very good one for any organisation willing to make an investment to evolve things.

But beyond just the image problem, there's also a functional problem with arbitrarily low password limits:

I've been through this myself in the past and I vividly recall creating a new PayPal password with 1Password only to find the one in my password manager had been truncated on the PayPal side and I was now locked out of my account. This is just unnecessary friction.

Summary

So wrapping it all up in reverse order, arbitrary low limits on length and character composition are bad. They look bad, they lead to negative speculation about security posture and they break tools like password managers.

But would I stop using a bank (as I've seen suggested in the past) solely due to their password policy? No, because authentication in this sector (and the other security controls that often accompany it) go far beyond just string-matching credentials.

Let's keep pushing banks to do better, but not lose our minds about it in the process.

Security Passwords Banks
Tweet Post Update Email RSS

Hi, I'm Troy Hunt, I write this blog, create courses for Pluralsight and am a Microsoft Regional Director and MVP who travels the world speaking at events and training technology professionals

Troy Hunt

Hi, I'm Troy Hunt, I write this blog, run "Have I Been Pwned" and am a Microsoft Regional Director and MVP who travels the world speaking at events and training technology professionals

Upcoming Events

I often run private workshops around these, here's upcoming events I'll be at:

Must Read

Don't have Pluralsight already? How about a 10 day free trial? That'll get you access to thousands of courses amongst which are dozens of my own including:

  1. OWASP Top 10 Web Application Security Risks for ASP.NET
  2. What Every Developer Must Know About HTTPS
  3. Hack Yourself First: How to go on the Cyber-Offense
  4. The Information Security Big Picture
  5. Ethical Hacking: Social Engineering
  6. Modernizing Your Websites with Azure Platform as a Service
  7. Introduction to Browser Security Headers
  8. Ethical Hacking: SQL Injection
  9. Web Security and the OWASP Top 10: The Big Picture
  10. Ethical Hacking: Hacking Web Applications