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
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?
New comment on your post “Habib Bank Limited (HBL) Internet Banking Security”
Author : Azeem (IP: 220.127.116.11 , 202-142-176-163.multi.net.pk)
E-mail : firstname.lastname@example.org
URL : http://azimyasin.wordpress.com
Whois : http://whois.arin.net/rest/ip/18.104.22.168
<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>
AAY!</p>You can see all comments on this post here:
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 websiteRegardsAAY!—————————————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——————————————
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?
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
> 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.
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.
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 happens1. Upon initialization of a ATD i.e. ( POS,InternetBanking,ATM) an ATD sends in a Init message(Initialization) to HSM2. 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-memory4. 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 values7. 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!
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 machineRegarding 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.I hope you would write a a corrigendum within your article of HBL using plain-text to store passwords.——————————————————-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 opinionput e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4 at http://www.md5decrypter.co.uk/ and you will get your hashed password in this case secretImagine storing hashes in database and some one with access to the db or some one invading an application and having access to thousands of hashesRegards,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 themP.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