Prof. Jayanth R. Varma's Financial Markets Blog

Photograph About
Prof. Jayanth R. Varma's Financial Markets Blog, A Blog on Financial Markets and Their Regulation

© Prof. Jayanth R. Varma

Subscribe to a feed
RSS Feed
Atom Feed
RSS Feed (Comments)

Follow on:

Sun Mon Tue Wed Thu Fri Sat

Powered by Blosxom

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:

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:

  1. The applicant fills the form online and submits the form.
  2. The system displays an acknowledgement which contains a unique 15-digit acknowledgement number.
  3. The applicant prints the acknowledgement, affixes the photograph, signs it, attaches relevant documents and mails it to the PAN Service Unit.
  4. 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     View/Post Comments (12)     permanent link