Habib Bank Limited (HBL) Internet Banking Security
Internet Banking is something that should be taken for granted. Every bank should offer it, no excuses. The same online banking services also need to ensure highest levels of security, no excuses.
The Habib Bank Limited (HBL) website has a glaring security gap in its HBL Internet Banking service, even though it may not be immediately apparent by just looking at the interface.
HBL Internet Banking requires users to enter a few select letters of their password by clicking on the virtual on-screen keyboard (they do it this way for other arguable reasons). The implementation of this implies that the password is stored in the database in plaint-text or similar—which is how they can verify individual letters of the password (Update: as verified by the HBL lead, they do not use one-way hashing or store combinations). Storing passwords in plain-text means that someone with access to the database can read them clear as day. You should never store passwords in plain-text and no one should ever be able to read your password.
Muslim Commercial Bank (MCB) also stores plain-text password, at least for password reset requests. Though the temporary password is set to expire within a day and it is possible they only store the temporary passwords in plain-text, it is still quite bad from a security standpoint, though not as bad as HBL’s implementation.
Update: though it is possible here that they generate a random password and only store the encrypted version, which would mean MCB is not storing it in plain-text. It seems that is likely the case, in which case this is perfectly acceptable behaviour.
You Just Don’t Store Passwords in Plain Text
It is a password after all. No one should have access to your passwords unless you explicitly let them in on the secret. Not even the developers at HBL or anyone in their IT team. Why should they? In the U.S. such behavior would even be deemed illegal since it is extremely negligent.
The problem is worse than it sounds. It is well known that most users reuse their passwords across different sites. If your HBL password gets compromised and you use the same password on another bank account, email account or social website, those accounts are now also compromised.
In HBL’s case, their database administrators can easily get access to thousands of account holders’ usernames and passwords.
And what if HBL servers ever get hacked? If the passwords were stored in their encrypted form instead of plain-text, a hacker would still have a hard time defrauding the accounts. But with plain-text passwords, a hacker would have instant access to every user’s password. He could then login as that user and HBL would never be the wiser because the hacker can log in through all the proper channels.
Even worse, undoing the damage after a security breach with plain-text passwords can be a nightmare. First, HBL would have to issue a notice to all users to change their password. It would also have to instruct them to change the password on any other account where they may have used the same password—quite embarrassing. HBL would then have to lock all accounts and disable user access to online banking until customers phone in or visit their nearest branch to have their passwords reset. Even then, it would have to disallow resetting the password to the previous one.
If even the most basic security best-practices were employed, the passwords would be much safer. These practices are so common, it is disconcerting to learn that the developers were oblivious to it and what other security blunders lurk within.
Technical Background: Passwords are encrypted with a one-way hashing algorithm that results in another reasonably long and convoluted string of text. Encrypting “
secret” this way would result in “
e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4”. For most practical purposes, the resulting text cannot be reversed to get “
secret”. So how do you verify if the user entered the correct password when logging in? You simply encrypt the entered password and verify that it results in “
e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4”. This makes it secure and no one ever needs to know your password.
Update: September 15, 2011
Some comments have asked how I came to the conclusion that passwords are stored in plain text. As I mention in the first paragraph–it’s not entirely obvious but if you have a basic understanding of password encryption schemes, you can draw some reasonable conclusions.
Passwords are stored using a one-way hashing algorithm. MD5 and SHA-1 are popular one-way hash functions for this purpose. As I mention in the technical details, all passwords are encrypted using similar cryptographic hash functions.
Why is it done this way?
It’s so that no one can reverse an encrypted password such as “
e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4”. That’s why it’s called a one-way hash function. Since all passwords are stored in the database in their encrypted form, they are secure. The encrypted password “
e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4” is quite useless to an attacker. He can’t do anything with it. He cannot reverse it to get the original passwords. That’s the beauty of one-way cryptographic hash functions.
If no one knows the password, how does the computer know the correct password was entered?
The computer asks the user for their password. It then encrypts whatever the user entered, using the same one-way hashing function and verifies that it results in the same encrypted password. If it does, the password entered was correct.
How do you know HBL is not using a one-way cryptographic hash function to encrypt their password?
When you encrypt “
secret”, it results in “
e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4”. But HBL asks you to enter specific characters. So say you enter “
r” and “
t”. In that case HBL would has to fill in the other blanks “
_ec_e_”. That shows that HBL knows a part of your password because it fills in these blanks for you.
But that’s only part of the password. Not the whole password, is it?
Well, HBL asks you to enter different letters from your password each time. That means it knows your full password and each time it fills in the remaining blanks. So on a subsequent login attempt it may ask you to fill in different blanks such as “
s__r_t” which means it knows the whole password.
I still don’t believe you. Are you making this up?
Don’t take my word for it. Try asking on stackoverflow.com or superuser.com or a serious security mailing list. Just refer them to this post and ask them for their opinion. If you want to discuss particulars or have some pressing concerns, you can find my email address at the bottom of my about page.
Update: September 17, 2011
The lead developer for HBL (Abdul Azeem Yasin) had this to say on the matter of one-way hashing of passwords:
Between your claim that SHA1 and md5 being the more secure way of storing password is again your opinion.
I could only hope that it was my opinion–and such a grand one at that. SHA-1 is the U.S federal standard (now being bumped by SHA-2). It was designed by the National Security Agency (NSA) which just happens to be cryptography intelligence agency of the U.S. Department of Defence.
And again, the lack of understanding is further exemplified:
put e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4 at http://www.md5decrypter.co.uk/ and you will get your hashed password in this case secret Imagine storing hashes in database and some one with access to the db or some one invading an application and having access to thousands of hashes :)
Rainbow table attacks aren’t new. That’s why you use a good password salt. You can also use bcrypt (which has built in salting and even harder to brute force).
You do realize that it would have been impossible to do partial password authentication in case of one way hashing.
He also continues to defend that an HSM is the equivalent of one-way hashing and that using public/private keys are a good way to go about it. Since the plain-text passwords are behind an HSM, that makes it okay. In fact, his explanation makes it clear:
Now when the user comes in to authenticate a pin verification message is sent to HSM in case of partial password a sentinel value is set i.e. if the password is abcdef123 and abcd is taken as an input from user abcd$$$$$ is sent to HSM by encrypting it with public key of HSM. HSM decrypts it and only check the password positions which are not sentinel values.
Which is like saying, since the HSM provides a very secure environment, you can stuff in there whatever you want. Doesn’t matter if it’s all your user’s passwords even though the means exist to encrypt each password individually. Nor does it help to allege that one-way password encryption is really something that is just my “opinion” (mine, and practically every operating system, major website and software company in the world).
What’s even more surprising is that he feels everyone is wrong and he is absolutely right. Reminds me of the the most popular security question on ServerFault about the most dangerous kind security auditor to have in your company, “Our security auditor is an idiot, how do I give him the information he wants“?