Apropos to Habib Bank Limited (HBL) Internet Banking Security

One good day i happen to get a link shared from one of my friend saying that you’re one of the developer various banks IB you should check this one out i responded back with my comments on that blog but soon i was moderated to respond on it and then a series of email exchange started between us .

Below is the email Chain

1st Email

——————————————————————————————-

So then you do concede that you or someone in your team has access to everyone’s plain-text passwords? Since HSM does have a key and someone knows that key. Is that correct?

Aleem

On Thu, Sep 15, 2011 at 10:47 PM, Azeem <wordpress@aleembawany.com> wrote:

New comment on your post “Habib Bank Limited (HBL) Internet Banking Security”
Author : Azeem (IP: 202.142.176.163 , 202-142-176-163.multi.net.pk)
E-mail : azimyasin@gmail.com
URL    : http://azimyasin.wordpress.com
Whois  : http://whois.arin.net/rest/ip/202.142.176.163
Comment:

<p>Dear Aleem, </p>

<p>I would again say  ”Neem Hakeem khatr-e-jaan” what you’re saying is that pins which are generated by HSM can be seen by anyone / every one , doesn’t that imply that ATM Pin codes that are generated via bank can be seen by bank employees and they can generate duplicate ATM cards and use your pin codes to withdraw your money . Spot on! (Y) You’re actually a geek and you have busted a secret out of banking industry please go on with suing all of those banks that uses partial password as their authentication methods which includes couple of ( swiss banks / world top notch banks ) :) </p>

<p>Regards,
AAY!</p>

Permalink: http://aleembawany.com/2011/09/10/habib-bank-limited-hbl-internet-banking-security/#comment-44090
Trash it: http://aleembawany.com/wordpress/wp-admin/comment.php?action=trash&c=44090
Spam it: http://aleembawany.com/wordpress/wp-admin/comment.php?action=spam&c=44090

My response 1

Dear Aleem,

You should go on with understanding  how Pin Mailer / HSM works no pin data are ever stored on any system . Upon initialization of an Alternative delivery channel HSM automatically generates a key and shares a public key with the delivery channel and then the ADC encrypts the pin with that public key and sends it back to HSM now that HSM have a key it stores the password no human intervention is involved neither any human have any access to any key. You should take a look at the product manual of an HSM provided on thales website :)
Regards
AAY!
—————————————
Second Email comes in
—————————————
As you said it uses a public/private key (asymmetric encryption). And it’s possible you encrypted the entire hard disk volume but either way you, or someone in your team has access to the private key which you can use to get access to the unencrypted volume. Is that correct?

Aleem
—————————————–
My Response 2
—————————————–
The answer is NO! Their is no way you can retrieve private keys out of an HSM . Otherwise the hardware wouldn’t cost in millions :)
——————————————

Third Email

——————————————

Private key need not be a text based key. You can use a digital card or other hardware tokens. You can even have coupled tokens where two people need to insert their tokens to gain unencrypted access to the machines. So you are saying that no one can decrypt the data and you didn’t get any hardware tokens or similar with your HSM setup?


Aleem

——————————————

My Response 3

——————————————-

HSM are booted by Hardware tokens . That hardware tokens are not used as a private key of ADC’s don’t you feel one can achieve the same task with a normal PC if it was that easy to access all the data? why to buy a 5/6 million hardware you can do it in a 25k MS SQL Server :)

———————————————

Fourth Email

———————————————

> Their is no way you can retrieve private keys out of an HSM

As a matter of fact, HSMs even allow you to backup the private key through smartcards or tokens.

What I said was that authorized persons can get access to the data as and when they please. The same tokens are also used for making backups.

And on the other hand what you are suggesting is that once the data goes into the data store, there is no way to get it out? Only to verify that it using yes/no responses?

—————————————-

My Response 4

—————————————

Yes that remains a fact. In case an anomaly occurs or an organization needs to fetch that data out of an HSM they need to contact back the vendor of HSM i.e. Safenet or thales and then only they can provide the actual buyer with the hardware key that be the private key and on most of the cases it remains with the actual vendor and it’s the contractual obligation of the HSM providing vendor to keep those keys safe once they sends back the private key to the real consumer the contract goes null and void i.e. that Hardware which costs in millions is no longer the safest place to keep pins  .

If getting private keys was that easy all ATM Pins would compromise with one person knowing pin codes of all consumer.

—————————————–

Fifth Email

—————————————–

If you never need to decrypt the data you don’t need asymmetric keys. You do understand how asymmetric keys work don’t you?
The key you are referring to may be the root key or some such key. The HSM does actually provide an API to generate keys to decrypt data. Anyone with sufficient privileges in your team can decrypt the data.
That’s why you are using asymmetric keys. To be able to get back out what you put in.
Otherwise you would use a one-way cryptographic hash. That’s why hackers use brute force dictionaries. I don’t think you really understand this concept.
You should consult your team lead or something and read up on the matter. If you are in IT operations (which it sounds like you might be), I would suggest you consult your software dev lead instead.

Aleem

——————————————–

My response 5

——————————————–

Dear Aleem ,

I do lead a team of 5 devs here :) . Asymmetric keys are used by HSM to do processing within it self.
Below is the overview of what actually happens
1. Upon initialization of a ATD i.e. ( POS,InternetBanking,ATM)  an ATD sends in a Init message(Initialization) to HSM
2. HSM Generates Public/Private key pair and stores it on a keyindex and sends in Public key as a response to this message . Only Keyindex / Public key are accsesible in HSM and no private key data is ever shown.
3. The ATD stores that Public key in its database or in-memory
4. Now lets say a user comes in and register his self on Internet banking . The IB Generates a random password encrypts it with Public key sent by HSM and send it back to HSM . HSM Responds with success / fail . If success HSM stores that pin in its database . If the ATD receive backs Success it sends that pin to consumer via email/sms what ever the organization decides.
5. 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 .
6. HSM decrypts it and only check the password positions which are not sentinel values
7. If the pin validates HSM responds back with success  and only then the user is able to login .
If you still don’t understand this discussion will never end. I still don’t think it’s wise to say the bank have stored the password in a MYSQL/MSSQL/ORACLE database in plain text format.
Regards,
AAY!

———————————————-

Sixth Email

———————————————-

Actually, it’s not that complex and I do understand what you are saying. Appears your HSM implementation is different and it doesn’t make all that much sense that you have entrusted your private key to another entity.


And you are mimicking one-way encryption by keeping the PK completely concealed. There is a reason why they invented one-way encryption functions. There’s also a reason why entire PHDs have been done on the same and why HSMs have encryption accelerators built into it.

Not to mention all other security considerations with essentially 4-letter passwords (brute forcing it would be trivial).

It might be useful for ATM and pins, but not for user passwords as such. One-way encryption algorithms achieve the same.

Also, I suspect that your SKU might be different, but a quick Google search shows that HSM APIs allow you to get the private key–maybe in your case they just stifled it. Either way, partial passwords are probably better done by generating one-way hashes of possible combinations and keeping the encrypted letter count high enough to avoid brute force (GPU based brute force attack would take a matter of hours if not days).

The analogy is that you have a really secure locker so you are storing everything in it (all your eggs in one basket). With each password individually encrypted using one-way functions, each password is it’s own unique locker. That’s common practise so a compromise doesn’t divulge every password or a brute force doesn’t screw things up. I still see this is as a big gap, though you have taken other measures against CSRF and two-factor auth.

If you just did a one-way encryption, you’d get the same functionality without an HSM (for this specific purpose) and would make it more secure. I am too lazy to find references, but this is also required for regulatory compliance. HSM might be entirely okay for storing other sensitive user data and key financial data or even ATM pins. But the very ethos of asymmetric keys is that you can encrypt and decrypt data. You are using it incorrectly.

Aleem
———————————-
My response 6
———————————-
Partial passwords are used to secure no-voice user from giving away their complete password in a keylogger/hacked machine

Regarding your other doubts that a 4 letter passwords is prone to brute force attack after 3 un-successful login attempt the account of the user is locked and the user have to visit the bank in order to reactivate their password.
You have agreed to the fact that the implementation i have mentioned in my reply makes it nearly impossible for any one to see what the user password is and now you’re arguing on the fact that you should have done one way hashing because you say so.
You do realize that it would have been impossible to do partial password authentication in case of one way hashing  and the users would have been more prone to keylogger based fraud/scams ? isn’t it ?
Either way your post saying HBL /MCB or any other bank have stored plain text password is plain wrong. I have worked for multiple banks within Pakistan/Middle east region and i can bet you on the fact that no bank would be fool enough to do what you have just said in your post its just that you don’t know how they have implemented their solution and you’re “assuming”. Moreover no compliance explicitly specify hashing as their recommended way of doing things they do however explicitly specify to not to store any sensitive data in any database/logs at least PA-DSS/ PCI-DSS doesn’t which is a industry standard.
——————————————————-
Another response of mine prior to receiving his response
——————————————————-
Between your claim that SHA1 and md5 being the more secure way of storing password is again your opinion

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 :)
Regards,
AAY!
—————————————-
Seventh Email
—————————————-
Are you saying SHA1 is insecure? Really? Do you even know how that website works (I haven’t looked but I have a good guess).
Brute force is not meant for online attempts. It’s for when your password bank gets compromised. You have a long way to go before you understand encryption. You have been given a password vault that you bought off the market and you are simply using that blindly after reading the manual. Doesn’t mean you really know the choice of encryption. Ignorance really is bliss.
————————————–
His 8th Email before reciving my response
————————————
Also, you can do partial auth with one-way. Read up on it.
====================
My final response
====================
You simply fail to realize that the encryption scheme.I provided in the algorithm doesn’t leak any information and no one get to know about any sensitive data. Rather you’re crying on the fact that i know better then you and you should follow me rather following any industry standard.

“HBL Stores plain text password” is a joke and you yourself are now telling me their are ways to store partial passwords without knowing them :)

P.S. Calling your self a security geek doesn’t makes you one make sure you secure the /pics/ folder at your website adding .htpasswd would be a good idea :)
For those who think private keys are accessible in HSM can take a look at http://forums.adobe.com/thread/831450  or http://www.openmpe.com/cslproceed/HPW04CD/papers/3327.pdf or you can refer to the HSM product manuals.
Moral of the story  ”Neem hakeem khatr-e-jaan” :)

~ by Azeem on September 16, 2011.

Posted in Uncategorized

2 Responses to “Apropos to Habib Bank Limited (HBL) Internet Banking Security”

  1. [...] Apropos to Habib Bank Limited (HBL) Internet Banking Security [...]

    Apropos to Habib Bank Limited (HBL) Internet Banking Security | Tea Break said this on September 16, 2011 at 9:40 pm | Reply

  2. This is called the man-in-the-middle attack and if you think about it, it’s pretty scary. Someone who man-in-the-middles your communications can trick you in any of a thousand ways.

    Of course, there’s a great way to get around the man-in-the-middle attack: use crypto. With crypto, it doesn’t matter if the enemy can see your messages, because he can’t decipher them, change them, and re-send them. That’s one of the main reasons to use crypto.

    But remember: for crypto to work, you need to have keys for the people you want to talk to. You and your partner need to share a secret or two, some keys that you can use to encrypt and decrypt your messages so that men-in-the-middle get locked out.

    That’s where the idea of public keys comes in. This is a little hairy, but it’s so unbelievably elegant too.

    In public key crypto, each user gets two keys. They’re long strings of mathematical gibberish, and they have an almost magic property. Whatever you scramble with one key, the other will unlock, and vice-versa. What’s more, they’re the only keys that can do this — if you can unscramble a message with one key, you know it was scrambled with the other (and vice-versa).

    So you take either one of these keys (it doesn’t matter which one) and you just publish it. You make it a total non-secret. You want anyone in the world to know what it is. For obvious reasons, they call this your “public key.”

    The other key, you hide in the darkest reaches of your mind. You protect it with your life. You never let anyone ever know what it is. That’s called your “private key.” (Duh.)

    Now say you’re a spy and you want to talk with your bosses. Their public key is known by everyone. Your public key is known by everyone. No one knows your private key but you. No one knows their private key but them.

    You want to send them a message. First, you encrypt it with your private key. You could just send that message along, and it would work pretty well, since they would know when the message arrived that it came from you. How? Because if they can decrypt it with your public key, it can only have been encrypted with your private key. This is the equivalent of putting your seal or signature on the bottom of a message. It says, “I wrote this, and no one else. No one could have tampered with it or changed it.”

    Unfortunately, this won’t actually keep your message a secret. That’s because your public key is really well known (it has to be, or you’ll be limited to sending messages to those few people who have your public key). Anyone who intercepts the message can read it. They can’t change it and make it seem like it came from you, but if you don’t want people to know what you’re saying, you need a better solution.

    So instead of just encrypting the message with your private key, you also encrypt it with your boss’s public key. Now it’s been locked twice. The first lock — the boss’s public key — only comes off when combined with your boss’s private key. The second lock — your private key — only comes off with your public key. When your bosses receive the message, they unlock it with both keys and now they know for sure that: a) you wrote it and b) only they can read it.

    It’s very cool. The day I discovered it, Darryl and I immediately exchanged keys and spent months cackling and rubbing our hands as we exchanged our military-grade secret messages about where to meet after school and whether Van would ever notice him.

    But if you want to understand security, you need to consider the most paranoid possibilities. Like, what if I tricked you into thinking that my public key was your boss’s public key? You’d encrypt the message with your private key and my public key. I’d decrypt it, read it, re-encrypt it with your boss’s real public key and send it on. As far as your boss knows, no one but you could have written the message and no one but him could have read it.

    And I get to sit in the middle, like a fat spider in a web, and all your secrets belong to me.

    Now, the easiest way to fix this is to really widely advertise your public key. If it’s really easy for anyone to know what your real key is, man-in-the-middle gets harder and harder. But you know what? Making things well-known is just as hard as keeping them secret. Think about it — how many billions of dollars are spent on shampoo ads and other crap, just to make sure that as many people know about something that some advertiser wants them to know?

    There’s a cheaper way of fixing man-in-the-middle: the web of trust. Say that before you leave HQ, you and your bosses sit down over coffee and actually tell each other your keys. No more man-in-the-middle! You’re absolutely certain whose keys you have, because they were put into your own hands.

    So far, so good. But there’s a natural limit to this: how many people can you physically meet with and swap keys? How many hours in the day do you want to devote to the equivalent of writing your own phone book? How many of those people are willing to devote that kind of time to you?

    Thinking about this like a phonebook helps. The world was once a place with a lot of phonebooks, and when you needed a number, you could look it up in the book. But for many of the numbers that you wanted to refer to on a given day, you would either know it by heart, or you’d be able to ask someone else. Even today, when I’m out with my cell-phone, I’ll ask Jolu or Darryl if they have a number I’m looking for. It’s faster and easier than looking it up online and they’re more reliable, too. If Jolu has a number, I trust him, so I trust the number, too. That’s called “transitive trust” — trust that moves across the web of our relationships.

    A web of trust is a bigger version of this. Say I meet Jolu and get his key. I can put it on my “keyring” — a list of keys that I’ve signed with my private key. That means you can unlock it with my public key and know for sure that me — or someone with my key, anyway — says that “this key belongs to this guy.”

    So I hand you my keyring and provided that you trust me to have actually met and verified all the keys on it, you can take it and add it to your keyring. Now, you meet someone else and you hand the whole ring to him. Bigger and bigger the ring grows, and provided that you trust the next guy in the chain, and he trusts the next guy in his chain and so on, you’re pretty secure.

    Cory Doctorow – Little Brother, Chapter 10.

    Abbas Halai said this on September 18, 2011 at 6:53 pm | Reply

Leave a Reply

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. ( Log Out / Change )

Twitter picture

You are commenting using your Twitter account. ( Log Out / Change )

Facebook photo

You are commenting using your Facebook account. ( Log Out / Change )

Cancel

Connecting to %s

 
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: