Earlier this year, Google made the announcement that 2-step verification is rolled out to all Google accounts. It requires the the user to provide one-time password (OTP) after entering the memorized password. One way to generate the OTP is via the mobile app Google Authenticator from a smart phone, which works very similar to two-factor authentication devices used by VeriSign VIP, RSA SecureID, and Yubikey. But there are a few things that make the OTP for Google accounts different from these two-factor authentication providers.
The first thing that we notice is that Google has made its OTP generation algorithm open-source, which is computed by synchronized time. Although the configuration user interface makes it a bit difficult to retrieve the key after the user initially sets up 2-step verification, the key itself is still available. Especially when the user has printed out the QR code (or simply instructed the web page to output the key string when configuring for a camera-less smart phone such as BlackBerry). One can scan the QR code again to get the key and re-load it on more than one device. I, for example, have managed to enable Google Authenticator on many different devices (one BlackBerry device and two Android devices) for my own convenience. So this ability fundamentally weakens "the second factor," which traditionally is something you own, in contrast to the password, which is something you know. One can argue, if you have multiple devices that can generate the same OTP, it is less likely that you can be sure that you have possession to all of them at all time.
Think about it, when you can write the key down or print the QR code out and later re-scan it, the OTP actually does not represent something that you owe, but another thing that you know about. So if a key logger can steal your password, another malware may steal the key to the OTP if you print the QR code into something like a PDF file, or store the key in a text file. With the published algorithm for generating the OTP, this method of the 2-step verification is really a two-password scheme.
Furthermore, with a single-password mechanism, the server should store the password as a salted one-way hash (neither as plain text nor as un-salted hash). In the event of internal attack, we have reasonable assurance that even if the master user database were to be breached, hackers would not easily extract the password from the hash. But it would be a totally different scenario with the OTP key, as Google must be able to decrypt it (if it is encrypted) from the user identity store to compute the OTP value to compare with user's submission. In some aspect, it would be harder for Google to protect this key than it would for the user password from internal attack. Theoretically speaking, it requires Google and users to raises the barrier to guard the OTP key.
It also makes Google the sole target for hackers as it must maintain both the password and the OTP key. In the case of Yubikey or VeriSign VIP, at least the key is stored by a third-party. We can only imagine that Google does this to lower the cost of providing more security without transferring the cost payable to such a third-party to consumers.
Don't get me wrong, even with these implications, 2-step verification makes account hacking a lot more difficult, as brute-force attack would introduce at least six digits to the existing password, making the attack space much bigger. Aside from that, the initial login process requires at least two HTTP requests to Google's servers, which tremendously slows down the rate of attacks that these hacks can achieve.
In conclusion, if you really want to use the most secure two-factor authentication, your only choice is not to use the Google Authenticator app, but activate 2-step verification via SMS. You also want to make sure that you provide a real mobile number to set up the SMS number, not using services that can relay SMS messages to other devices, which probably excludes Sprint devices that are linked to Google Voice. This is the only way to ensure that you would have a single device to receive the authentication code. However, there is other issues with the SMS mechanism, such as its failure to work when the phone is not in range of any cell towers, or when the carrier has problem that delays the SMS delivery. Most importantly, you pay the usurious SMS rate for every OTP you receive, if you do not already have the unlimited SMS plan, which is equally exorbitant.
Monday, October 3, 2011
Monday, June 13, 2011
The Cost of Encryption
For Matrix fans, the green letter-fall on a computer screen was symbolic of a view into an exotic world that is based on machine languages, cryptic to naked eyes. In another word, encryption was sexy and hard to attain for some regular Joe.
Flash forward a decade, technology has advanced so much and there are a wealth of digital security tools available to corporations and consumers alike. With powerful, free and open-source software such as TrueCrypt, we are entering into a new world where security conscious users embrace crypto technologies more than ever. Ubuntu offers whole disk encryption right out of the box. More companies issue laptops to employees that are equiped with Trusted Platform Modules (TPM) to secure corporate assets thereof. The old way of protecting a hard drive via a BIOS password is no longer sufficient nowadays.
Recently, I purchased a few large capacity (2TB) hard disk drives as my offline storage for personal backup files. I tried to set up these drives with whole disck encryption using TrueCrypt.
I first started initializing one disk from a newly built computer. It has an AMD four-core CPU clocked at 3.4GHz. The bare drive was mounted in a docking station that plugged into the USB 3.0 port. Once I started the process, it said that I had to wait for four hours, and the initial write was progressing at a rate of 122MB/s. I knew it would take some time since I had done something like this before. A few hours was what I had in mind, so I turned off the flat screen monitor and let it run.
As I had another drives to initialize, I started the same process from a spare laptop that is over six years old. That laptop has an Intel Pentium single-core CPU (1.6GHz) that runs Windows XP Service Pack 3. I immediately noticed that the wizard advised about 25 hours. Uh, what? 25 hours? That was way beyond what I had expected. When I last checked, the encryption was moving along at a rate of 20.4MB/s. The raw math says that it would be almost 30 hours, but I knew the speed would vary when the drive head moves away from the center of the platters, so it would pick up steam later. Nevertheless, the rate is pathetic in my opinion. I mean the USB 2.0 dock for these bare drives should give me 480MB/s, no? As I poked around, I noticed that the CPU consumption was a sustained 80% while there was no other application running. The bottleneck has got to be due to the computational burden when the initialization process writes pseudo-randon 0's and 1's to the drive. Then I looked at the power consumption from my UPS unit. It was about 36W when I closed the laptop lid to save the 9W from the LCD.
That accounts for 0.9 kWh, which is about 10 cents damage to my electric bill. Not a big deal, you would say. But I felt dumbfounded, because the long wait that I had to endure. Formatting a disk is just to prepare a disk for normal use, and it takes over one day and uses all that computing power of the poor little laptop. Wow! Imagine, during the life of that encrypted hard drive, I may operating many hours of read and writes, all of which would involve encryption and decryption, which are computationally intensive operations. The cost of employing encryption would be orders of magnitude higher, would I choose not to encrypt.
Meanwhile, the faster machine consumed about 190W, while eating up 30% of overal CPU cycles. So the initialization would cost slightly less power, not not orders of magnitude less.
Furthermore, when I use an unencrypted hard drive, the disk writes involve those bytes that are affected. However, because of the nature of the encryption, the entire block has to be re-calculated and re-written. So more computations and more writes. A lot more.
Here is the thought, when the technology affords better improvement in terms of speed and efficiency, we tend to leverage the technology to do more complex things. So the efficiency gain does not translate to overall productivity gain. Encryption along is net new operation spend that could be prohibitively costly, should we not have the luxury of fast computers.
Security has never been so prevalent these days, in the advent of major cyber hacks from Sony to International Monetary Fund. Why don't they have better security? Whey don't they encrypt the data and traffic? We ask. The truth is security comes at a price.
Some people criticize Amazon cloud storage service for not providing data encryption. In contrast, Dropbox does encrypt customer's files in the cloud storage. Put aside who owns the encryption keys, Dropbox must absorb the additional cost of encrypting and decrypting documents. That cost is not a trivial. We might have someone calculate the additional carbon footprint due to encryption, to know the environmental impact for those added security.
Encryption is the basis of all security. It is not cheap. It costs money. That is IT!
Flash forward a decade, technology has advanced so much and there are a wealth of digital security tools available to corporations and consumers alike. With powerful, free and open-source software such as TrueCrypt, we are entering into a new world where security conscious users embrace crypto technologies more than ever. Ubuntu offers whole disk encryption right out of the box. More companies issue laptops to employees that are equiped with Trusted Platform Modules (TPM) to secure corporate assets thereof. The old way of protecting a hard drive via a BIOS password is no longer sufficient nowadays.
Recently, I purchased a few large capacity (2TB) hard disk drives as my offline storage for personal backup files. I tried to set up these drives with whole disck encryption using TrueCrypt.
I first started initializing one disk from a newly built computer. It has an AMD four-core CPU clocked at 3.4GHz. The bare drive was mounted in a docking station that plugged into the USB 3.0 port. Once I started the process, it said that I had to wait for four hours, and the initial write was progressing at a rate of 122MB/s. I knew it would take some time since I had done something like this before. A few hours was what I had in mind, so I turned off the flat screen monitor and let it run.
As I had another drives to initialize, I started the same process from a spare laptop that is over six years old. That laptop has an Intel Pentium single-core CPU (1.6GHz) that runs Windows XP Service Pack 3. I immediately noticed that the wizard advised about 25 hours. Uh, what? 25 hours? That was way beyond what I had expected. When I last checked, the encryption was moving along at a rate of 20.4MB/s. The raw math says that it would be almost 30 hours, but I knew the speed would vary when the drive head moves away from the center of the platters, so it would pick up steam later. Nevertheless, the rate is pathetic in my opinion. I mean the USB 2.0 dock for these bare drives should give me 480MB/s, no? As I poked around, I noticed that the CPU consumption was a sustained 80% while there was no other application running. The bottleneck has got to be due to the computational burden when the initialization process writes pseudo-randon 0's and 1's to the drive. Then I looked at the power consumption from my UPS unit. It was about 36W when I closed the laptop lid to save the 9W from the LCD.
That accounts for 0.9 kWh, which is about 10 cents damage to my electric bill. Not a big deal, you would say. But I felt dumbfounded, because the long wait that I had to endure. Formatting a disk is just to prepare a disk for normal use, and it takes over one day and uses all that computing power of the poor little laptop. Wow! Imagine, during the life of that encrypted hard drive, I may operating many hours of read and writes, all of which would involve encryption and decryption, which are computationally intensive operations. The cost of employing encryption would be orders of magnitude higher, would I choose not to encrypt.
Meanwhile, the faster machine consumed about 190W, while eating up 30% of overal CPU cycles. So the initialization would cost slightly less power, not not orders of magnitude less.
Furthermore, when I use an unencrypted hard drive, the disk writes involve those bytes that are affected. However, because of the nature of the encryption, the entire block has to be re-calculated and re-written. So more computations and more writes. A lot more.
Here is the thought, when the technology affords better improvement in terms of speed and efficiency, we tend to leverage the technology to do more complex things. So the efficiency gain does not translate to overall productivity gain. Encryption along is net new operation spend that could be prohibitively costly, should we not have the luxury of fast computers.
Security has never been so prevalent these days, in the advent of major cyber hacks from Sony to International Monetary Fund. Why don't they have better security? Whey don't they encrypt the data and traffic? We ask. The truth is security comes at a price.
Some people criticize Amazon cloud storage service for not providing data encryption. In contrast, Dropbox does encrypt customer's files in the cloud storage. Put aside who owns the encryption keys, Dropbox must absorb the additional cost of encrypting and decrypting documents. That cost is not a trivial. We might have someone calculate the additional carbon footprint due to encryption, to know the environmental impact for those added security.
Encryption is the basis of all security. It is not cheap. It costs money. That is IT!
Subscribe to:
Posts (Atom)