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 “s”, “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.
Impossible, really?
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“?
Thanks for share, internet banking is a simple way to help us in the management of financial information through a digital world. :D
Thanks for sharing this .. but i can not believe that HBL and MCB are storing plain password. The thought you are sharing about password manipulation is not acceptable. As I believe system must have encrypted emphasized text password and they are verifying or matching password on Business logic layer by some algorithm. And if it is true then HBL and MCB should pay an attention on the implementation. And also this is a shameful implementation done by the or propose by development company.
Best Regards
Syed faisal
Dear Author
How do you know that passwords are stored in the plain text at HBL? Do you have any proof?
Regards
Arif
Give us proof,dude.
You wrote such a longggggggggggg story .. but haven’t provided any proof!! I want to know how do you know that passwords are in plain text?
Hi!
Sir ya proof kai kam hay k abhe tak HBL ki tarf say kisi na bhe comment naeh kia..
Dear Author ,
Being one of the developer of an internet banking product you’re referring in your post . The post may fascinate a layman but for a typical Banker working in Information technology group it would look like some joke. No passwords/PINs are ever saved on a banking channel itself they are rather saved on a Switch/HSM and it’s the responsibility of an HSM to respond back with an answer of YES/NO i.e. the authenticity of password. Having passwords in plain text is a simple joke.
If you were a true security analyst you would have realized that the password input mechanism only takes input from virtual keyboard with a partial password. This in it self is a security hardening procedure that stops any key-logger / hacker to get the password of a user.
Hope this would clear some of your doubts :)
Regards,
Abdul Azeem
I don’t which is scarier. The fact that you are a developer for HBL and don’t recognize the obvious security issue here. Or the fact that despite this being a very trivial security concern, you still continue to defend your current practise (in which case your ignorance is the reason why this may never get fixed).
Dear Aleem,
What i can make out from your discussion is that “You’re not willing to understand how financial system work” . Financial systems are not simple as you thought of them to be they are not websites which you are “assuming” them to be :). Please google “HSM” (Hardware Security Module) DMZ( Demilitarized Zone) Three tier Architecture. Moreover all the financial systems have to go through a tough line of Audit / Compliance which you might not know of. As said in a famous proverb “Neem hakeem khatra-e-jaan”. I would really like to recommend you to sue HBL/MCB after which you might be able to understand how complex things goes around :).
Regards,
AAY!
Between you should take a chance with suing HSBC/Citibank as well they do ask for partial password as well :)
The HSM has a key. With that key you can decrypt all the data in the database. I am sure your leads have those keys and they also have backups to prevent accidental lockout. As Fahd pointed out and I repeatedly explain in my post, this isn’t one-way hashing.
If I store all my website’s user passwords in a text file but encrypt my hard disk, doesn’t make it okay. I still can read all their passwords using the key I have.
HSM may be a concept new and novel to you. Once the novelty wears out, and maybe a few months or years from now when you’ve had more experience, you’ll probably realize how foolish you sound. Your confidence comes from your ignorance.
Or maybe instead of asking everyone to Google it, you can in your infinite wisdom tell us how HSM prevents someone in your team with the key to access all the data including unencrypted passwords.
Dear Author
It might be possible that HBL IT staff won’t have enough time to respond to such lame blogs/articles which are not supported by facts/proofs.
Try to include some strong proof instead of asking another question.
Regards
Arif
This article is a great example why people should not speak about things they don’t know off!
–
UZ
This article is a great example of the fact that you should not speak about things you don’t know about!
What is shown on screen and what goes on behind are two totally different things.
Although, on a serious note though, if you are a customer of either of these banks you should seriously look to sue the bank as they are exposing you to these risks. Even if you are not using these services, contact those who are, make them aware, contact bank and ask them to improve their systems and tell them if they don’t they will face legal action.
This is not a small thing to be allowed to continue unabated.
Dear Author,
Where are you, if you are not able to respond this article this means that you are not sure about what you have written.
Also one more this I have posted this article on facebook HBL page but no one of HBL represented are interested to give any response, which means that there are something wrong with there implementation
Best Reagrds
Syd Faisal
I have updated the post to address some of the questions and concerns raised in the comments.
For people who really do know: the clinker is – how can any algorithm return a match to a partial password that is encrypted by a one way hash. Unless, HBL uses a 2 way asynchronous encryption algorithm, then the question arises – what are they using as the private/public key to decrypt the password to match? And this is wrought with other security considerations.
For people still asking for proof, I suggest you brush up on your cryptography. Shouting and/or being abusive does not make you right.
Please google “HSM” ( Hardware Security module ) and get your skilled brushed as well
LOL…. Kindly sue HBL and MCB instead of wasting time in discussion.
Dear all,
Meezan bank also following this technique(plain password) :P
https://ebanking.meezanbank.com/ambit/UserNamelogin.do
Best Regards
Faisal
16 Sep ’11
Aleem, great post.
What about this, I do the following:
Step 1:
I store in my DB hashes for 8 combinations in 8 columns. So in a table password, I have 9 columns:
userid, combo1_hash, combo2_hash, .., combo8_hash
Step 2:
My web-app is hard coded with presenting the user 1 of the 8 combos (so, I make it non-random to some extent)
combo1: 1, 2, 4, 5
combo2: 1, 3, 6, 7
..
combo8: 2, 3, 4, 5 (this is used in your Shot)
Step 3:
Now, when the web-application presents the keyboard, it knows it is presenting combo8.
Step 4:
Now, we hash what user entered, and compare this with hash in column 8.
Final Word:
The reason they have done on-screen keyboard is clear (key logging software). Why they have done 4 out of 8, I discussed with a very senior member in their IT Team, who I really admire, and he basically said there is no clear reason. At that time, I didn’t think about what you have written and could not challenge him on that, but knowing him for past 4 years, I know that they are using the technique I mention or some other elegant way of doing things.
There is a step 1.1, in which the application receives the 8 character password, splits it in 8 different combos, and stores 8 hashes (instead of a normal web-app which stores hash of full password)
Of course, when I say web-app / DB, I am not using the financial industry terms such as HSM, etc. But high level concept stays the same. The combinations are well defined, and a 1-way hash is stored for these well defined combos.
Actually it’s well documented you need not re-invent the wheel:
http://www.smartarchitects.co.uk/news/9/15/Partial-Passwords—How.html
Though the over-simplified approach is to simply hash the combinations which is what I proposed to him over email yesterday (I have been communicating with him), to which his response was firstly:
Clearly the gentleman does not understand security. And then again,
Clearly, he is enlightened in all matters of security!
Those quotes are taken verbatim from his mails. A person who doesn’t understand the simple basics should really not be trusted with security, let alone be allowed to lead a team.
There is a big difference between buying an HSM secured-vault and putting everything inside it blindly (that’s the IT manager approach) versus truly having an understanding of encryption schemes and using the right one.
This is exactly what I thought while reading the article.
And btw, if you have experienced VBV (Verified By Visa) or Mastercard Securecode security check, they also ask you for random characters of your password. I can’t imagine VBV storing passwords as plain text.
It’s entirely possible and I very well could have been wrong and they could have actually gone to great lengths to do this, but apparently they didn’t.
An HSM is his panacea and answer to all his problems.
BTW, this web-application is developed not internally at HBL, but instead purchased from TPS. I assume multiple banks have purchased same/similar platforms.
From where I see to this scenario, with the asked “clear text” words probably a hash generated and it would be cross checked with the stored hashed data in the DB “password” field. Supposing user-id is clear-text and two same words generates the same hash code.
Azeem, write a password on a piece of paper.
Store the paper in a bank locker which for the sake of argument, is unbreakable but has 5 keys.
Is the password now safe? Yes, it is – but only until you can protect the key. If there are 5 copies of the locker key, are you still protected?
Wouldn’t it be better, if you had encrypted the password on paper, before storing it in the locker? Even if someone broke into the locker and got the piece of paper, they will get a random string. Depending on the length, difficulty of password and the hashing algorithm used, it can take them decades to decypher it, or, if its a simple one, they can break it via md5decrypters within seconds.
Makes high level sense to you now? This is all Aleem has been trying to ‘tell’ you. Don’t take it personally.
http://azimyasin.wordpress.com/2011/09/16/apropos-to-habib-bank-limited-hbl-internet-banking-security/
You might want to look at the My response 5 part of it.
Thanks, that’s pretty much what it boils down to in layman’s terms.
Though not quite if you use a good password salt which is again, standard practice. It protects your from rainbow table attacks such as MD5 decrypter which isn’t really a “decrypter” in the strict sense.
As a side note, it is also recommended to use SHA-1 (or even SHA-2) over MD5.
What are you,a conspiracy theorist ?? trying to scare innocent people ? lol..Dude you need to understand how the HSM works in collabration with Pakistani ATM switches.You’ll learn that it is always better to research first rather then trying to prove baseless ideology to innocent people.
This is not about ATM switches. Might want to read the post again.
[...] user using partial passwords, store the passwords in plain text?I recently read an article on this: http://aleembawany.com/2011/09/1…Cannot add comment if you are logged out. Add [...]