About Fri, 24 Jun 2011
Sending internet banking passwords by mail
I have observed banks in India use several different ways to send internet banking passwords to their customers, but from a security point of view all these methods are totally unsatisfactory:
- Some banks send the username and password in two separate envelopes by ordinary mail usually with a time gap of a couple of days. The mailer is so designed that the password cannot be read (at least by the naked eye) without tearing it open. The only security here is that even if one of the envelopes is stolen or tampered with, the account is not compromised. Customers love this method because it is the most hassle free and simple mechanism. Banks like this because it allows them to centralize password issuance at a central location where it is easier to control operational risk. Moreover, because of centralization, it is possible to generate and print passwords only as needed. Since printed passwords do not have to be stored for long periods, the risk of their being compromised by insiders is reduced. However, this method of password dissemination also poses the biggest security risk at the customer end. Any person staying in the same house has the opportunity to take possession of both the username and the password; the account is then completely compromised.
- A less common variant of the above method is one where the bank requires the customer to send a signed acknowledgement of having received the password before activating the internet banking facility. This is a powerful security measure, but to make the process more convenient, these banks typically allow the acknowledgement to be sent by fax or email (scanned image). This makes the method useless because it is quite trivial to scan a signature from some other document and superimpose it on the scanned image of the acknowledgement form.
- Some banks (particularly public sector banks) require the customer to come to the bank in person to collect the username and password. Customers (especially the younger generation to whom a bank means an ATM and not a branch) hate this because they are today accustomed to getting everything sitting at home. The direct security risk is low in this method, but there are severe operational risks. Thousands of envelopes containing usernames and passwords are stored for long periods of time in hundreds of branches across the country. If even one pair (of usernames and passwords) is compromised, a rogue employee might be able to arrange matters in such a way as to assign this pair to a vulnerable account (an account with a large balance that is monitored infrequently). Moreover general bank staff in the branches are not particularly sensitive to password security. Sharing of password between different staff members is quite rampant in many branches and there is often a culture of not taking security precautions seriously. Some bank staff are themselves not aware of the nuances of internet banking and often give wrong instructions to customers. All of these increase security risks.
Many people think that these security risks are trivial and unavoidable. Subconsciously, they think that the bank must anyway store the password somewhere to verify the password that the user types in. But this is wrong. Computers never store user passwords at all – at least they are not supposed to do so. What is stored is a secure cryptographic hash of the password from which the password cannot be recovered with any reasonable amount of computational effort. When a user tries to log in, what happens is that the computer applies the same secure cryptographic hash to the password that the user typed in. If this hash matches the stored password hash, the computer accepts the password as correct and carefully erases (from its own memory) the password that it just read in from the user. Good software programmers are so paranoid about this that before they read the password that a user is typing in, they take care to lock the memory location into RAM (for example, by using mlock in unix) so that during the few milliseconds that the plain text password exists in the computer’s memory, this password is not accidentally written to the hard disk when the operating system manages its virtual memory.
Looking at things with this background, it appears to me that any system in which a password exists in plain text printed form even for a few minutes (let alone several days) is an unacceptable and intolerable level of security risk.
There is also a very simple solution to the problem. The most secure way of sending a password to the customer is not to send the password at all! This requires that the bank should not generate the password in the first place. If the user generates the password, then there is no need to send the password to him at all. This thought occurred to me when I was examining the process of applying for a PAN number online (A similar process is used for online filing of income tax returns also.). This process addresses the same problem that the bank faces – a PAN number cannot be allotted without receiving signed documents in physical form:
- The applicant fills the form online and submits the form.
- The system displays an acknowledgement which contains a unique 15-digit acknowledgement number.
- The applicant prints the acknowledgement, affixes the photograph, signs it, attaches relevant documents and mails it to the PAN Service Unit.
- At the PAN Service Unit, the 15-digit acknowledgement number provides the link between the physical records and the online application to enable processing of the application.
This process can be adapted to the internet banking password problem as follows. The customer applies for internet banking online and chooses a password. As usual, the system stores a a secure cryptographic hash of the password but does not enable the online banking facility at this stage. The system generates an acknowledgement number and lets the customer print out an application form which includes this acknowledgement number. The customer mails this form duly signed to the bank. After the bank verifies the signature and other documents, it simply enables the password that the user has already generated. At all times, this password is known only to the user; neither does the bank records this password on paper nor does it store the password electronically in plain text.
Posted at 14:23 on Fri, 24 Jun 2011 10 comments permanent link
Comments...
Anil Satpute wrote on Sat, 25 Jun 2011 13:14
Re: Sending internet banking passwords by mail
Good article about internet banking security and has good insight about matching and retriving password during login process.
Not a security expert, but with little common sense wrote on Sat, 25 Jun 2011 14:00
Re: Sending internet banking passwords by mail
Professor, your approach as mentioned in the end is also not risk proof. The fundamental requirement in this transaction business is to always 'match' the user provided password with a 'stored' password which is saved somewhere & somehow. There is no way one can authorize a user generated password. If you hash map this plain text password, ultimately you have to 'match' this hashed password with something....right??
Prof. Jayanth R. Varma wrote on Tue, 28 Jun 2011 13:17
Re: Re: Sending internet banking passwords by mail
Perhaps an example will make this clear. Suppose the user chooses the password "AWeakPassword". The computer does not store "AWeakPassword" anywhere. Instead it creates and stores a hash of this password. Let me use the MD5 hashing method as an example because I happen to have MD5 software readily available (MD5 is no longer recommended for actual use).
The hash using MD5 is "e2637e37610972c655943737ef5e5f64". This is what the computer stores on the hard disk. Suppose a user tries to log in using a wrong password "AWeakpassword" (the p is not capitalized, but otherwise the password is correct). The computer finds the MD5 hash of this attempted password which is "c6bcbdeeae2fd3d6f68b34fb511e32ad". (One of the properties of a good hash is that though the attempted password is almost correct, the hash is totally different as in this case).
The computer compares the computed hash value "c6bcbdeeae2fd3d6f68b34fb511e32ad" with the stored hash value "e2637e37610972c655943737ef5e5f64". Since the values do not match, the computer rejects the login attempt.
The whole point is that the computer can recognize the correct password when it is entered, but it can not recall what it is.
ketan wrote on Mon, 27 Jun 2011 14:24
Re: Sending internet banking passwords by mail
Amazing!
Finance blogs wrote on Tue, 28 Jun 2011 10:42
www.msn.com
I am very thankful to Prof. Jayanth R. Varma for explaining the pros and cons of "sending internet banking password by mail".This is the very important blog everybody must go through it.
Divyansh Agrawal wrote on Tue, 28 Jun 2011 15:18
Re: Sending internet banking passwords by mail
Interesting topic.
I would like to add the method of ICICI Bank and Bank of Maharashtra.
ICICI Bank: They send user id, login password, transaction password by 3 different physical mail all have to be changed on first login, and at the time of transaction one should have ATM card (which is linked with account) to verify the owner (by entering some specific numbers printed on backside of the card)and transaction can be processed thereafter only.
Bank of Maharashtra : They send user id and password on email but before using this facility one has to activate it by calling to customer care, they ask user id and some information that you filled in bank account opening form to verify that you owns the account and they activate it (customer care executive neither ask for your login password nor he have access to it) and , chances of theft are only when someone has access to all your information and you mobile & email to call and activate online banking (on first login both login and transaction passwords have to be changed so that even if your e-mail is hacked someone can not login).
Theodore wrote on Thu, 30 Jun 2011 18:58
Re: Sending internet banking passwords by mail
Excellent article. The fact is that problems are often left at solutions that are only 'good enough'.
Brilliant analysis and solution in the article.
I agree that: 1. Computers don't store the pwd.. they store hashes 2. The current methods are not secure enough 3. There are much better alternatives if people put their mind to it.
Trivial suggestions to add to the article: I suggest dual authentication using any two out of the following: i) One-time-password on SMS to authenticate user through Mobile number ii) Customer calls the helpline and authenticates himself using personal information iii) E-mail confirmation link confirms the person has access to customer's email account also iv) Customer enters ATM pin in the online facility right there to authenticate himself v) Get an activation code on web page and go type it into that bank's ATM (special feature needed in ATM) vi) Print, sign and send acknowledgement slip generated on the web vii) Any other secure method
Rahul wrote on Thu, 21 Jul 2011 14:40
Re: Sending internet banking passwords by mail
Good article sir.
I had another idea that might be useful. How about user choosing the password himself/herself in the bank along with filling in the application form. The form can have electronic components, that include the password. Once the bank has completed the formalities, they can send cutstomer a letter informing him/her of the user id, at which time the earlier selected password becomes valid.
Shashi wrote on Sat, 13 Aug 2011 14:26
Re: Sending internet banking passwords by mail
Prof Varma in the solution which you suggested in the last paragraph... it starts with the assumption that only the customer applies but couldn't an impostor start the whole said process mentioned and proceed to gain control of the customers account without his knowledge....?
Prof. Jayanth R. Varma wrote on Tue, 16 Aug 2011 13:50
Re: Re: Sending internet banking passwords by mail
The solution assumes that the bank can verify he customer's signature. If the imposter can forge the signature, then he can as well forge the signature on a cheque to steal the money.
