A few days ago, I logged in to my Internet banking account with DBS, South East Asia's largest bank by assets, and decided to change my login password.

Take a look at the password page:

See anything strange? (POSB is owned by DBS, so I'm not referring to the branding here.)

First, only digits allowed, no alphabetical or other characters. Of course, this isn't uncommon for banks because they're wired to think in terms of ATMs that only have numeric keypads. Alright, I guess we'll let that pass for now.

What's more puzzling is:

- The PIN must be 6 to 9 digits long.
- No repeated digits allowed.
- No consecutive digits allowed.

Woah, now!

DBS probably thinks they have enhanced security by applying these restrictions ("ah, our customers can't use stupid passwords like 123456 or 999999, so they're safe from hacking") but they've actually reduced security dramatically. Why?

Let's take two scenarios:

- 6 digit PIN. Repeated digits allowed. Consecutive digits allowed.
- 6 digit PIN. No repeats allowed. Consecutive digits allowed.

Which scenario do you think has more potential PIN combinations?

In scenario 1, the number of possible PINs is n^{r}, where n is the total number of digits available to choose from (in our case, the 10 digits from 0 to 9) and r is the number of digits we want to choose (in our case, 6). So the number of possible PINs is 10^{6} or 1 million.

In scenario 2, for sake of simplicity (ahem), I've pretended that consecutive digits are allowed. In this case, the number of possible PINs is n!/(n-r)! where ! is the factorial operator. This is 10!/(10-6)! which works out to 151,200.

That means, just by including one restriction -- no repeated digits -- the number of possible PINs has dropped by almost 85% from 1 million to 151,200.

If you add the further restriction that consecutive digits are not allowed, then potential PINs like 942317 also disappear from the list of possibilities, because they contain the digits 2 and 3 in consecutive positions. Calculating how many such numbers would be disallowed is an exercise left to the reader.

Let's now look at 9-digit PINs with the same two scenarios above.

In scenario 1, the number of possible PINs is 10^{9} or 1 billion. In scenario 2 (with consecutive digits allowed), the number of possible PINs is 3,628,800.

Therefore, the number of possible PINs has dropped by more than 99.6%.

So let's summarise:

Number of digits |
Possible PINs in scenario 1 |
Possible PINs in scenario 2 | Drop % |
---|---|---|---|

6 | 1,000,000 | 151,200 | 84.9% |

7 | 10,000,000 | 604,800 | 94.0% |

8 | 100,000,000 | 1,814,400 | 98.2% |

9 | 1,000,000,000 | 3,628,800 | 99.6% |

Total across all PIN lengths |
1,111,000,000 | 6,199,200 | 99.4% |

Simply by disallowing repeat digits, DBS reduces the number of possible PINs from 1.1 billion to just over 6 million. Disallow consecutive digits and the number drops even more.

What does this mean? It means that if someone wanted to use brute force to crack an account-holder's password, they could do it *at least* 99.4% quicker than otherwise. If they wanted to further optimise their brute force method, they would drop passwords that contained consecutive digits.

But that's still several million possible password combinations, right? And that would make a brute force method impractical? As it turns out, hardly.

Given standard hardware, one could easily achieve rates of anywhere from 500 to 2,000 transactions per second today, and possibly much more with an optimised number-generation algorithm. And TPS will continue to improve by leaps and bounds over time.

This implies that someone who really wanted to crack a password via a straightforward brute-force method would need well under an hour to at most a couple of hours to get through.

This is the hacker's worst case. Obviously, the *average* case will be much shorter, because once you've found the correct PIN, you don't need to keep running the algorithm all the way through the entire list of possible PINs.

In comparison, Scenario 1 would take several days to crack via brute force. Allow non-numerical characters and you immediately multiply the time need for brute force by several times.

Am I missing something? After all, they did get hacked not once but *twice* just a year ago.

Now, I'm not claiming that the password is the one and only line of security. Nor am I claiming that DBS's systems would not notice hundreds of login requests sent each second by a potential hacker.

But what I *am* curious to know is why they would turn their backs on such an easy addition to their lines of defence -- simply allow their customers to pick an *easily remembered, yet hard to hack* password out of more than a billion combinations instead of just a few million. Possibly disallow a few obviously poor combinations such as 123456 and 999999, but that's it. Even better: allow non-numerical characters.

Before you ask, that phrase "easily remembered, yet hard to hack" isn't wishful thinking. This xkcd comic explains why. Gotta love the caption at the bottom!

Click to see original

If you don't understand what the comic is saying, try this explanation.

I used this page for some of the calculations above but they're straightforward to do by hand.

**Update:** a few people asked me what a better password is. As the xkcd explanation page says,

Steve Gibson from the Security Now podcast did a lot of work in this arena and found that this password

`D0g.....................`

(24 characters long) is stronger than`PrXyc.N(n4k77#L!eVdAfp9`

(23 characters long) because both have at least one uppercase letter, lowercase letter, number, and "special" character, so length trumps perceived complexity.

That probably explains as clearly as possible what an "easily remembered, yet hard to hack" password is.

## Comments