Google Analytics

Tuesday, May 10

The saga of plain text password

Recently, one of the major Indian payment gateways, CCAvenue was reported to have been hacked. Medianama has good coverage of it including an interview with the very bureaucratic sounding CEO of the company.

While a payment gateway getting hacked is a big news, the bigger revelation were the clear text passwords that came out of the compromised database. There have been a lot of comments and discussions about this all over the startup blogs. Reading through those comments it appeared to me that there is a lot of confusion regarding passwords and how to securely store and transmit them. Saurabh Nanda has a good little primer about things to read. This is my attempt to clarify some of the things involved.

First a few basics. Any situation that involves passwords has 2 parties. The aim is to establish identity between parties. For simplicity, we will assume that it is the user that wants to establish his identity with the service. Login/Password system works on the basis of a shared secret. You tell the service the correct shared secret and it identifies you. One important thing to remember here is that the secret is being established between the user and the service only and not between the user and the employees of the company providing the service. For example, we would not want a database admin in Google to be able to read all our mails.

On to the specific questions.

Is it ever OK to store password in plain text?

There are 2 scenarios of an application dealing with passwords. One is of a web app like Gmail that allows people to sign up and hence must keep track of login passwords. The other is of intermediate apps like browsers that store users credentials for various services to make it more convenient for users. The answer for the first kind of applications is "never". The answer for the second kind of applications is "if done properly".

Basically, the applications in second category need access to the original password when logging in the user to service provider. So they cannot hash the password and store that. They can certainly encrypt it but that may or may not be any more secure then a plain text password stored properly. Even here, adoption of OAuth is reducing the need to deal with user passwords directly.

What is the difference between Encryption and Hashing?

Encrypted things can be decrypted if the key is available. So it only pushes back the question of security one layer deep. How do you ensure the security of the key? You can encrypt that also but then you need to safeguard the key-key. You get the drift.

Hashing is a one way road. A good hashing function has 2 properties: hash value of 2 different inputs is different. And given the hash value, it is extremely difficult (computationally) to retrieve the input string. Because of the first property, we can safely store the hash value in place of the original password. Whenever we need to match, we can just compute the hash and match it to the stored value. Because of the second property, even if someone gets access to the hash values, they cannot recover the password easily.

Are all hashing functions created equal?

No. In the past decade, the commonly used hash functions like MD5 and SHA-1 have been successfully attacked. So the current recommendation is to use SHA-256, SHA-512. However the suggested best choice for password hashing is bcrypt. The advantage of bcrypt is that you can tune it to be as slow as required. How does that help? Well, it increases the resources required to mount a brute force attack significantly. Normal hash functions are built to be very fast. As a result, attacker can compute hashes of millions of passwords per second. With bcrypt, that number goes down several notches and makes the approach unfeasible.

Why is is OK to receive a one time password in plain text?

Since the service should never store the original password in plain text, if the user forgets the password, the only way out is for him to choose a new password. To allow that the service needs a way to establish his identity. This can be done with the help of security questions. A more popular way is to send a mail to the registered email address of the user.

Now if the reset password email contains your original password in plain text, that is a huge red flag. This means that the site stored your original password. Remember that it is not possible to recover original password from the hash.

But it is ok if the mail contains a one time password in plain text. This password is not meant to be stored and used more than once. So even if someone gets access to it, there is no issue. If on the other hand, if someone intercepts your mail and gets access to it before you do, even a hashed/encrypted password will not make much of a difference. The way to prevent the snooping is to use https for your mail and other sensitive connections.

Perhaps this is nothing new for most people but given that even Reddit guys were found storing plain text passwords, it is always good to double check on your security practices.

No comments: