Online file-backup and storage service Dropbox has begun offering a two-step authentication feature to help users beef up the security of their accounts. The promised change comes less than a month after the compromise of a Dropbox employee’s account exposed many Dropbox user email addresses.
Dropbox users can take advantage of the new security measure by logging in at this link, and then clicking the “Security” tab. Under account sign in, click the link next to “Two-step verification.” You’ll have the option of getting security code sent to your mobile device, or using one of several mobile apps that leverage the Time-based One-Time Password algorithm.
If you’re already familiar with the Google Authenticator app for Gmail’s two-step verification process (available for Android/iPhone/BlackBerry) this is a no-brainer: When prompted, open the app and create a new token, then use the app to scan the bar code on your computer screen. Enter the key generated by the app into your account settings on the site, and you’re done. Other supported apps include Amazon AWS MFA (Android) and Authenticator (Windows Phone 7).
Note that DropBox users will need to download the latest version of the Dropbox client (1.4.17 on Windows/Mac) to access their files via the Dropbox desktop software interface after enabling two-step authentication.
Some readers have asked which method of two-step verification is more secure: Text message or mobile app? Text messages are perhaps faster and easier, but they introduce yet another potential avenue of compromise: The mobile provider. In a recent attack against the chief executive of Cloudflare, for example, miscreants were able to break into the executive’s Gmail account even though he had instructed Google’s 2-step verification feature to send codes to his phone. That attack succeeded because the miscreants were able to trick a customer service representative at his mobile phone provider — AT&T — into forwarding his messages to another account.
well, stays the question how secure the file hosters itself are?
I doubt that business data has to be stored on hosters like dropbox…
As always, good post!
Its a good step for certain but when one considers 2fa-Enabled fraud or that users will almost certainly select the weaker 2fa options like “only prompt every “X” days for pin code” efficacy will get diluted in a short period of time.
and OOB verification is moot in when the device is compromised anyways…..
Two-step authentication is better, but it does not beat client-side encryption.
Two factor authentication is a good step away from simple passwords, but the fact that Dropbox does your file encryption on their servers means that your data is not safe from that employee whose account is compromised or the search demands of government agencies. Get a service that encrypts on your side of the connection.
The latest version appears to be 1.4.17
Thanks. They must have shipped a new version overnight.
Good, clear post Brian!
Q:
My mom (back in Europe),
is 76 and
does _not_ use/have a cell phone.
She uses her PC for
Gmail and Dropbox,
and would like to use 2-step Authentication.
What can I do to help her?
Is there any other way for Mom to receive
the code each time she logs in
to Gmail or Dropbox?
I guess the folks
at Gmail or Dropbox,
have not thought about this scenario.
(many, many people out there with a PC,
but without a cell phone…).
Any suggestions welcome…thanks!
For Gmail you have the choice between text message (cell phone) and voice message (regular phone).
I guess your mom has at least a regular phone?
Using 2FA is predicated on a user’s willingness & ability to use two distinct factors: something they know (a password) and something they have (a device by which they obtain a transient PIN.) Users unable or unwilling to use such a second-factor device cannot use 2FA.
As a practical matter, Google’s 2FA has a voice call option which might work for your mom, although I’m not sure if it can be set up without having the actual Authenticator app running on some device. The easiest solution might be for her to get an iPod Touch, which will run the Google Authenticator app just fine without needing to deal with a mobile phone. That can be a very low-cost choice if she is willing to use a second-hand device, as a 2nd-gen model would serve that limited purpose. It should also be possible to get an otherwise obsolete Android device and put the Authenticator app on it.
Thanks Bill Cole & Louis,
for the good advice.
Indeed –
an old iPod Touch
or
old Android device,
just for running the Google Authenticator app. –
sounds like a really good & low cost idea,
in Mom’s case.
Have her sign up for Google Voice (assuming it’s available outside the US). GV has web-based text messages, no need for a cell phone.
I use my personal GV account as the authenticator # for one of my Gmail email accounts (a different one that the one that is tied to the GV account). This way if I ever lose my cell phone (heaven forbid!) I could still authenticate for Gmail.
GV doesn’t cost anything, all you need is a Gmail account to sign up.
Google recommends NOT using GV for getting 2FA codes (http://support.google.com/accounts/bin/answer.py?hl=en&answer=185839) and there’s a good security reason for that. If the password to your 2FA-protected account is compromised, there’s a very good chance that ALL of your passwords will be compromised along with it, including the one to GV.
A safer backstop that Google offers for losing your second factor device is to print (NOT save to disk) a set of “backup codes” (http://support.google.com/accounts/bin/answer.py?hl=en&answer=1187538) that you can generate in batches of 10 and use one time each. You can keep the code card wherever you keep other cards you don’t want to lose, and as long as you resist the temptation to carry around a record of what account they are for and what the password to that is, it is harmless to lose them. When you generate a new batch the old ones are disabled.
These are the issues with any 2FA system: losing the ability to authenticate is easier, the whole process is less convenient, and the obvious tricks to mitigate those problems are likely to weaken the independence of the 2 factors.
And in a SUPREME bit of irony, I had to authenticate with Gmail to get this comment. 🙂
The problem with this is that for one, the commenter I was replying to was looking for a way *other than* using a cell phone (his mom doesn’t have one); and two…Google restricts each cell phone to ONE account. While you may be lucky enough to have more than one cell phone, I don’t.
The backup codes sounds good in theory, but I’ve found Google/Gmail’s 2-step identification to be less than perfect. I have to reauthenticate my computers anywhere from every 2 days to every 2 weeks, rather than the “remember me for 30 days” as it’s supposed to work.
As for your comment “If the password to your 2FA-protected account is compromised, there’s a very good chance that ALL of your passwords will be compromised along with it, including the one to GV”, I can’t for the life of me see how one is related to another, unless someone had all the same passwords, stored passwords in the email, etc.
And I’m truly not being a smart ass…I don’t see the connection.
If you are referring to the use of the Authenticator app on a phone, it is not true that Google only allows one account per phone. See http://support.google.com/accounts/bin/answer.py?hl=en&answer=185834#multiple. I have 2 accounts set up to use the Authenticator app I have on an iPod Touch, proving that you don’t even need one phone to use 2FA with multiple accounts.
As for the ways losing one password can mean you’ve lost them all, one of the most common ways that passwords get into the wrong hands is via a malware infection. Keyloggers and disk scanners in malware payloads mean that any password typed in or stashed on the disk while infected will be lost. Even for users of smarter tools like encrypted keyrings for passwords are likely to loose the whole thing if infected because at some point while infected they will type in a master password to decrypt the keyring and the malware slurps up that password and the keyring. Password-saving tools on mobile devices are worse, with many of them not even bothering to encrypt their data so if you lose the device, all the passwords can be extracted. In the realm of things a user cannot control, we’ve seen the demonstration of many service providers losing whole poorly-protected databases to attackers, and while I suspect Google is hardened against such a loss better than others, they may not be and if they managed to leak the password to one of your accounts they would stand a strong chance of having leaked the password to all of your accounts with them. And of course there are those simple bits of stupid like using the same password everywhere or using a pattern that makes all passwords easily guessed once one is known.
It’s certainly possible to lose control of a password in a way that does not threaten others, but that is not the most common sorts of compromise these days. Since 2FA exists to protect against password compromise, it doesn’t make a lot of sense to weaken it against common modes of compromise.
Well first of all, the Google support link results in a blank page. And Google Voice/Gmail/Google most certainly DOES limit each phone number to one account. The only way around that is list the number as a “home” or “work” number (as opposed to a cell phone. This is extremely well covered in the Google support groups. Here’s but one example:
http://productforums.google.com/forum/#!topic/voice/rDKUvIq8Xf8
As for the rest of your reasoning behind not using a GV # as an authenticator…you forgot about the possibility of a herd of wild elephants charging through my office and trampling my computer and cell phone, then stealing my lunch money.
NONE of what you’ve listed has any bearing whatsoever to the use of a Google Voice number to receive SMS authentication notifications.
Good suggestion, Mara.
Checked – but unfortunately, Google Voice is not available outside the US…
Thanks for the post Brian. I’ve updated to the version and enabled two-step verification. My bank uses the same type of security when changes are made to any accounts so I’m comfortable with it.
I’ve also been looking at adding client side encryption with TrueCrypt. That would add another layer of protection, wouldn’t it (from both inside and outside prying eyes)?
Hi Tom,
There are two ways to use TrueCrypt – either for your disc partitions or ‘file-hosted,’ which puts files of your choosing into an encrypted container (much like using 7zip to create a AES-encrypted .7z ‘zip’ file).
Let’s say for example you’re working on a laptop, and you’ve used TrueCrypt to encrypt the entire system and data partitions. When the computer is off the contents of the hard drive would appear meaningless. When the computer is running, however, files on your hard drive are decrypted on-the-fly so that they reside in your RAM in a usable form. In this case, given that DropBox doesn’t encrypt the files before sending, the data in question would be sent over in cleartext.
In contrast if you use TrueCrypt to encrypt a file container it will load even into your RAM still in encrypted form (until you decrypt the container). Sending a file this way to DropBox would be more secure (assuming you haven’t been compromised and since opened the container).
Personally I find 7zip’s AES-256 encrypted .7z containers more convenient to work with for quickly packing up files for transmission over the internet. Since this is for storage though I think your TrueCrypt idea is a great one.
Andrew Zizzo sayeth:
>> “I find 7zip’s AES-256 encrypted .7z containers more convenient to work with for quickly packing up files for transmission over the internet.”…
– Yes, that’s exactly what I do before sending a sensitive file to Dropbox.
Simple & effective…
Remember that if you make your encrypted container file large, like a folder of multiple files, any changes to it will require that the entire container file will have to be sent to the DropBox (or other similar service) server.
This may be important if your Internet connection is slow or usage metered.
Also remember you have to set Truecrypt so it updates the “Last Modified” date on the container when it writes to the data inside. Otherwise, it stays the same as always, and Dropbox doesn’t know to update the file – it checks by date when deciding to sync.
I am glad to see them implement 2-Factor Authentication. It is definitely better than the other option one-factor. I feel suspicious when I am not asked to telesign into my account by way of 2FA, it just feels as if they are not offering my sites enough protection. Just the fact that we are still living in a password world is annoying. Almost everything is still only password protected. But ultimately the fact is passwords (strong or not) do not replace the need for other effective security control.
OTP Tokens regardless of how you receive your PIN or Code is NOT 2-Factor Authentication. If the user must enter the PIN or Code it is just like entering your Username and Password. So it is still Single Factor authentication and can still be stolen by today’s online exploits such as a Zeus Trojan that uses a real-time Keylogger. Since such Trojans operate in real-time, even the OTP Tokens that change the PIN every minute are still Single Factor Authentication and easily stolen and used immediately by the hacker to access an online account.
So DropBox is NOT implementing 2-Factor Authentication! Passwords and PIN codes entered by the user are both something the user KNOWS and neither are someting the user HAS. A smartcard or a USB token that automatically send a dynamic encrypted code to the authentication server are something the user HAS. SoundPass software that also automatically sends an encrypted code to the authentication server is something the user HAS.
Therefore, instead of using 2 single factors of Username and Password you will now be using 3 single factors and paying for the phone call. Real-time Keyloggers used in todays malware don’t care how many passwords and codes the user enters as it will copy and steal them all.
I think that’s why it’s called “2-step authentication,” not 2-factor authentication.
Mike, doesn’t Soundpass rely on having Java installed on your system? Personally, I could not with a straight face recommend any security solution that depended on Java being installed.
Yes it is called “2-step authenticati0n” and if you read the comments from many of your readers they are stating how good it is for DropBox to be implementing 2-factor authentication.
2-step is a far cry from 2-factor and this 2-step is basically useless.
Regarding Java….. About 99% of all PC’s and Mac’s have Java already installed. SoundPass only uses Java to generate an applet used to automatically create a virtual dynamic token credential, encrypt it, and automatically send it to the authentication server.
IT Examiners are already stating that SoundPass is stronger authentication security than anything else they have seen for online banking. If any attack is made against Java the software that resides only on the authentication server will not function as designed and will therefore not allow access to the online account. Therefore, your online bank account will remain secure along with your hard earned money.
You should review the entire SoundPass design before you conclude that Java is a problem because in this application it is not an issue. If C++ or any other program would have been stronger than Java, we would have used it. When we start to protect Mobile Banking, we will use something other than Java because Java is not used on most phones. Consumers should have the best possible protection available and for our SoundPass design Java was and still is the best.