But, that’s always easier said than done, and once again we are faced with yet another security incident that is being poorly handled by those who are tasked with protecting the privacy as well as the financial information of their customers. Before we get down to the nitty-gritty details, this is what CIMB should have told you weeks ago, but even today, after the social media storm that has taken place, they have yet to enforce a mandatory password change for ALL their users. Finally, do a quick check on your Debit Card transactions over the last three months, and see if there is any suspicious transactions. These transactions will be of values generally under RM50 to avoid raising an alarm. We are aware of the other issues related to CIMB Malaysia, but to avoid any overlaps, we will only be looking at the password issue in this post.

That 8 character password

The 8 character issue with CIMB Malaysia’s password is not something new. Frankly speaking, we were able to trace it back all the way to 2011 based on complaints on social media in relation to their constant changing of their password policy. https://twitter.com/imranjaafar/status/71475995244376065 All the passwords i have used with CIMB Clicks Malaysia myself have always been more then 12 characters. Never have i had an 8 character password, but at some point in time, the policy did change – and the passwords were limited to 8 characters. Now this in itself is not a simple exercise to do, because even based on the above tweet, when the password length was trimmed down to 8 characters, those with longer passwords were not able to login (without having to change their passwords).

How to change your Password Policy and retain old passwords in 2 minutes

So, when the new password policy came into effect, CIMB Malaysia somehow decided that instead of compelling all users to do a password change to adhere to the new policy, they would instead allow both new and old passwords to co-exist simultaneously. And instead of making massive changes to how their system would allow this to be done securely, they chose a very simple, insecure, and downright nasty way of doing it. Coding is an artform, and any self respecting coder would not be using this piece of code to check for the passwords to his grandmothers basement, let alone on the front end of a major Online Banking system. Essentially, what the code does is this. So, when this code came into effect, even if you had a password of  15 or 20 characters before November 18, 2018, only the first 8 would be need to be correct to gain access to your account. While this does not automatically grant anybody access to your account, it greatly increases the chances of someone who more or less knows your password habits to guess the right password. IF NOT, JUST MATCH THE FIRST 8 CHARACTERS Now, if your password was a combination of letters and numbers, it would be harder to crack, but there are a lot of people who use just numbers as their password. How long does it take to crack a 8 character all number password – about 5 minutes.

Whats that reCaptcha doing there?

One of the first tell tale signs that something was seriously wrong with CIMB Clicks Malaysia was when they suddenly, without any warning decided to implement a reCaptcha authentication on their site. This of cause was after the CIMB Clicks platform was completely inaccessible for most of Saturday.

Some smaller banks around the world do turn to Google’s reCaptcha to keep away unwanted traffic because its free, and extremely easy to implement, but to say reCaptcha has been implemented to enhance customers’ security is nothing but a blatant lie. What reCaptcha does is slows down spam bots (and in the case of CIMB Clicks brute force scripts) from hammering their system with millions of queries as it tries every single password combination to get into a customers account.

There are so many more elegant, secure and much more effective ways to keep spam bots, nasty scripts and even malicious users away, and reCaptcha does not figure anywhere on this list for an organisation of this size.

To hash or not to hash

We are going to get a little technical here for the last bit, so turn away now if you must. Based on the minified javascript we went through on the CIMB Clicks site, we are fairly certain that post 18th November, the passwords are now stored in a one way hash algorithm, making them quite secure in the event of any future breaches. However, we are now somewhat concerned on how the passwords were stored before November 18th. There are generally two ways that passwords are usually stored on the backend databases of any systems (we say two, because we are hoping to God that it isn’t stored in plaintext). It could have been encrypted, or it could have been hashed. Now the good thing about hashed passwords is, even without a salt value, it is pretty much one way traffic. While not entirely impossible to reverse the hash, it is going to take you forever and a day to retrieve the actual plain text password. So going back to the CIMB Clicks issue, if the passwords post 18th November were hashed, it would have been quite impossible for them to have played around with the number of characters – simply because there is no way of knowing the first 8 characters of the password, or even correctly guessing how many characters were in the password to start with just from the hash stored on the database. For a quick example on how a MD5 has works, see below. MD5 is a popular hashing algorithm that we are using in this example, but in no way is an algorithm that is recommended these days. As you can see, even one letter change, completely changes the MD5 hashing result, and in a hashed system, only the hash is stored in the password field. You can test it yourself here. String: lowyat (no caps) MD5 Hash: 9a7485524402678db8c71d5fddaad6d6 String lowyat1 MD5 Hash : 39b53cce07126625efedf6c4826bab65 So, unless CIMB has been only hashing the first 8 letters all the way back from 2011, it is looking very unlikely that the customers passwords were hashed. Which leaves us with the passwords being encrypted (again we are hoping its not plain text!). Encrypting passwords works as well, but the big issue with encryption as seen from the illustration above is that, anybody with a decryption key will be able to reverse the password from its encrypted form to a plain text form. More often then not, the encryption key will be a single key across the entire data set. Even if its not, it is very likely that the decryption keys will be stored within the database itself. If the passwords were indeed encrypted, then it would be entirely possible to change the number of characters required for the password to be accepted as required by their password policies. However, this also means that anybody with access to the database very probably also has access to your plain text passwords. Now, remember a little over a year ago when CIMB Malaysia lost their backup magnetic tapes? Lets all now pray that the data contained in these tapes was hashed and not encrypted.