A blog on financial markets and their regulation
Sending internet banking passwords by mail
June 24, 2011Posted by on
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.