SMS does not provide true two factor authentication

I am a strong supporter of two factor authentication (2FA), and I welcomed the idea of a one time password sent by SMS when it was introduced in India a few years ago. But gradually I have become disillusioned because SMS is not true 2FA.

Authentication is a problem that humanity has faced for centuries; and long before computers were invented, several authentication methods were developed and adopted. Two widely used methods are nicely illustrated by two different stories in the centuries old collection Arabian Nights. The first method is to authenticate with something that you know like Open Sesame in Ali Baba and the Forty Thieves. The Ali Baba story describes how the secret password is easily stolen during the process of authentication itself. What is worse is that while we would quickly detect the theft of a physical object, the theft of a secret password is not detected unless the theft does something stupid like Ali Baba’s brother did in the story.

The second method is to authenticate with something that you have, and its problems are eloquently portrayed in the story about Aladdin’s Wonderful Lamp. In the Aladdin story, the lamp changes hand involuntarily at least four times; physical keys or hardware tokens can also be stolen. The problem is that while you can carry “what you know” with you all the time (if you have committed it to memory), you cannot carry “what you have” with you all the time. When you leave it behind, you may (like Aladdin) find on your return that it is gone.

Clearly, the two methods – “what you know” and “what you have” – are complementary in that one is strong where the other is weak. Naturally, centuries ago, people came up with the idea of combining the two methods. This is the core idea of 2FA – you authenticate with something that you have and with something that you know. An interesting example of 2FA can be found in the Indian epic, the Ramayana. There is an episode in this epic where Rama sends a messenger (Hanuman) to his wife Sita. Since Hanuman was previously unknown to Sita, there was clearly a problem of authentication to be solved. Rama gives some personal ornaments to Hanuman which he could show to Sita for the “what you have” part of 2FA. But Rama does not rely on this alone. He also narrates some incidents known only to Rama and Sita to provide the “what you know” part of 2FA. The Ramayana records that the authentication was successful in a hostile environment where Sita regarded everything with suspicion (because her captors were adept in various forms of sorcery).

In the digital world, 2FA relies on a password for the “what you know” part and some piece of hardware for the “what you have” part. In high value applications, a hardware token – a kind of electronic key – is common. While it is vulnerable to MitM attacks, I like to think of this as reasonably secure (maybe I am just deluded). The kind of person who can steal your password is probably sitting in Nigeria or Ukraine, while the person who can steal your hardware must be living relatively close by. The skill sets required for the two thefts are quite different and it is unlikely that the same person would have both skill sets. The few people like Richard Feynman who are equally good at picking locks and cracking the secrets of the universe hopefully have better things to do in life than hack into your bank account.

The SMS based OTP has emerged as the poor man’s substitute for a hardware token. The bank sends you a text message with a one time password which you type in on the web site as the second factor in the authentication. Intuitively, your mobile phone becomes the the “what you have” part of 2FA.

Unfortunately, this intuition is all wrong – horribly wrong. The SMS which the bank sends is sent to your mobile number and not to your mobile phone. This might appear to be an exercise in hair splitting, but it is very important. The problem is that while my mobile phone is something that I have, my SIM card and mobile connection are both in the telecom operator’s hands and not in mine.

There have been cases around the world where somebody claiming to be you convinces the telecom operator that you have lost your mobile and need a new SIM card with the old number. The operator simply deactivates your SIM and gives the fake you a new SIM which has been assigned the old number. If you think this is a figment of my paranoid imagination, take a look at this 2013 story from India and this 2011 story from Malaysia. If you want something from the developed world, look at this 2011 story from Australia about how the crook simply went to another telecom operator and asked for the number to be “ported” from the original operator. (h/t I came across all these stories directly or indirectly via Bruce Schneier at different points of time). I have blogged about this problem in the past as well (see here and here).

My final illustration of why the SMS OTP that is sent to you is totally divorced from your mobile phone is provided by my own experience last week in Gujarat. In the wake of rioting in parts of the state, the government asked the telecom operators to shut down SMS services and mobile data throughout the state. I needed to book an air ticket urgently one night for a visiting relative who had to rush back because of an emergency at home. Using a wired internet connection, I could login to the bank site using my password (the “what I know” part of 2FA). The mobile phone (the “what I have” part of 2FA) was securely in my hand. All to no avail, because the telecom operator would not send me the SMS containing the OTP. I had to call somebody from outside the state to make the payment.

This also set me thinking that someday a criminal gang would (a) steal credit cards, (b) engineer some disorder to get SMS services shut down, and (c) use this “cover of darkness” to steal money using those cards. They would know that the victims would not receive the SMS messages that would otherwise alert them to the fraud.

I think we need to rethink the SMS OTP model. Perhaps, we need to protect the SIM with something like a Trusted Platform Module (TPM). The operator may be able to give away your SIM to a thief, but it cannot do anything about your TPM – it would truly be “something that you ” have. Or maybe the OTP must come via a secure channel different from normal SMS.

Online submission in an offline examination

This might seem impossible, but the magic of cryptography makes many things possible.

For many years now, my examinations have followed the open book and open laptop model. However, to prevent collaboration, the Internet is disabled by switching off the WiFi network inside the examination hall. This means that it is not possible for the students to submit their answer sheets electronically. They can use spreadsheets to compute the answers and perform the requested analysis, but at the end they have to transcribe the answers to the good old paper answer sheets and submit these handwritten sheets. This not only leads to duplication of effort but also gives rise to the possibility of errors in copying from the spreadsheet to the paper sheets.

After many years of living with this situation, my co-instructor and I finally decided to use cryptography to solve this problem. Students were asked to prepare the electronic answer sheet inside the examination hall (where the Internet is disabled) and then submit this file electronically after leaving the examination hall and connecting to the Internet outside the hall. Cryptography is critical to ensure that the file that they submit outside the hall is the same as the file that they had prepared inside the hall.

Specifically, we use a cryptographic hash function or message digest. The secure one-way hash function takes arbitrary-sized data (the message) and outputs a fixed-length hash value – for example, a 40 digit number. The cryptographic properties of the hash function that make it so useful are:

  1. Reversing the process and computing the message from its hash is computationally infeasible.

  2. Even minor changes in the message lead to large changes in the hash value, and it is computationally infeasible to modify the message in such a way that the hash does not change.

  3. It is computationally infeasible to generate collision (two different messages with the same hash).

The way we use this is that before students leave the examination hall, they are required to compute the secure hash of the file that they intend to submit and write this number down in the old style handwritten answer sheet. The paper answer sheet thus contains only the name and the hash of their file; it is perhaps the shortest answer sheet that they have ever submitted. Within a few hours, they are required to submit their electronic answer sheet by email or by web upload. On receiving the electronic submission, we compute the hash and verify that it matches the value in the handwritten answer sheet.

There are many possible secure hash functions that could be used. We had two criteria in making this choice. First the hash function must be so widely used that many software applications are available to compute it on all possible computer platforms: Windows, Linux and Mac. This really narrows down the choice to MD5 and SHA1. Second, the hash function must be secure given today’s computing capabilities and current cryptographic knowledge. This ruled out MD5 which is today regarded as already broken. It is true that SHA1 is also being deprecated today, but this is really a judgement that it could be broken in the near future. In our judgement, SHA1 is sufficiently secure for our purposes where the stakes are not so high that the resources of a nation state or other similarly well endowed adversary may be deployed against us.

We pointed students to QuickHash which is a cross platform utility for computing SHA1 hashes using a graphical interface. Students were however free to use any other utility including standard command line tools in Linux and Mac (like sha1sum and openssl).

One final consideration was the choice of the file format. We decided to accept only PDF files. Our experience with project submissions is that a spreadsheet file submission puts the onus on the instructor to figure out whether the correct answer is present in some nook or corner of a large spreadsheet. It also puts us in the unenviable situation of having to make sense of a poorly documented spreadsheet. Since today almost all software applications provide a PDF export facility, the choice of the PDF format is not restrictive.

When we tried this out in a class of 65 students this month, the entire process went off quite smoothly. We did not have even one case of a mismatch in hash sums. This gives us the confidence to use this methodology more extensively in future.

Using Encryption

Computer users live in a dangerous world filled with evil characters. Mathematics is our only friend; it allows us to encrypt important things and protect them from the prying eyes of strangers and black hats. Of course, encryption depends on the hope that P ≠ NP, but that is far better than depending on the kindness of strangers. Let us look at a few scenarios:

  • Laptops can be stolen, and then the original owner can only hope for the kindness of the thief not to misuse the sensitive data in the stolen laptop before reformatting the hard disk for his own use. Unless the data was encrypted before it was stolen.
  • Computers often have to be given for repair, and the owner depends on the kindness of the technician not to misuse the sensitive data in the machine while repairing it. Unless the data was encrypted before the machine failed.

  • USB sticks and external hard disks that use flash storage are another big headache because (a) they are more easily lost and (b) it is very hard to securely delete data from that short of physically destroying the device. Writing only encrypted data onto these devices is a much better solution than looking for a hammer after you have written data unencrypted.

There are two broad philosophies when it comes to encryption. The first approach believes in encrypting everything: HTTPS-everywhere and Full Disk Encryption are examples of this approach. The second approach is to encrypt only the sensitive data and leave the rest unencrypted. Truly paranoid people might combine both these approaches by encrypting sensitive files and placing these encrypted files inside a disk which is itself under Full Disk Encryption with a different password.

The level of security required also depends on the threat model. My threat model is that somebody might steal my laptop for its hardware value and then having taken possession of it might also try to read what is there. If you engaged in a conflict with an oppressive government or a powerful criminal organization, your threat model might be the reverse: somebody might steal or grab your laptop with the sole purpose of reading the data – the hardware itself is worthless to this kind of thief. I like to hope and believe that I am not in the second category, though this could well be a delusion.

My use of encryption is based on the assumption that

  1. I need to protect only my sensitive files and not everything, and
  • I need protection only against casual intruders and not against a nation state or a malicious and talented group of hackers.

  • Given the above, I would like to have the luxury of (a) setting up multiple users who can use the system independently, (b) using hibernation, (c) installing multiple operating systems sharing the same home partition. Each of these might weaken the security against a determined hacker, but might be tolerable weaknesses given my threat model.
    Continue Reading