Dropbox enables two-factor verification in “experimental build”

Company suggests that the new more-secure feature will be released this week.

Roughly a month after Dropbox said it would offer two-factor authentication, the cloud-based storage company has quietly done so in an experimental build of the application. In the wake of the Mat Honan hack and Dropbox’s own security problems, the company seems to have taken a stronger tactic for hardening user accounts.

In a discussion in the company’s online forums, Jie T., a Dropbox developer, said the company would be adding two-step verification as an optional add-on “sometime in the next few days.”

“Two-step verification adds an extra layer of protection to your account by requiring an additional security code that is sent to your phone by text message or generated using a mobile authenticator app,” he wrote last Friday. “We'd like to give our loyal forum viewers a chance to try it out first.”

To use it before the official release comes out, Dropbox users have to upgrade to the latest “forum build,” version 1.5.12. Once that’s installed, users are required to click the two-step verification link and enable the option.

Similar to Google’s two-factor authentication for Gmail users, Dropbox’s version gives the option of receiving a text message with a six-number code, or a private list of codes that can be used offline.

The company has remained quiet on both its Twitter account and its blog regarding when this build of the application will be rolled out officially.

24 Reader Comments

I can only hope this is the start of a wave of corporations (So far Google, Steam, and Dropbox showing themselves to be good corporate citizens int his manner at least) making it possible for consumers to engage in better security practices, since many of these businesses have show themselves unable to keep our information safe. Although I realize that possibly for hacking is never zero, when using two factor authentication with a unique secure password kept in keepass or lastpass, I think the amount of vulnerability your average consumer has drops to a reasonably low level.

I know that Steam does this 2-step verification too, and seems like a good idea when potentially private files are at stake. Having said that I'm not sure what Dropbox uses as its file transport if it's encrypted end-to-end anyway.

While I wish more places would add standardized PKI-based systems, something like this is comparatively easier and is a step in the right direction. Most of all it's definitely good to see more widespread thinking and awareness about improving authentication. It's been one of the glaring weak spots in the modern networked world for a long time, even though the technology is around to improve it. Anything that helps add momentum for change is a win.

dooferorg wrote:

Having said that I'm not sure what Dropbox uses as its file transport if it's encrypted end-to-end anyway.

Dropbox does not have end-to-end crypto, they themselves do have access to everything. You have to layer it with a container (TrueCrypt for example) or handle it per-file (like password managers) if you want that level of security, or else use another service.

I think this is great, but beta testing two-factor auth for a critical service is a pretty bad idea. I'll wait till they deem it ready, and then another couple of days to make sure there are no other issues.

I'm beginning to think we need a standard Authenticator implementation, though. Any reason not to just use Google's Authenticator for everything? I'm already up to four separate apps :-/

I turned this on yesterday and you can use Google's Authenticator. In theory, you should be able to use whichever you want as long as it supports OATH.

You can use google's implementation for OAuth's HMAC one-time-pad on any PAM-enabled service (read: anything that runs on linux somewhere). Just search for "google authenticator $FAVORITE_LANGUAGE" for an implementation. It's really a simple and clear standard.

I just turned on 2-step for SU'ing on a server here as an experiment. Wow! I'm kinda tempted to tell people that we'll only allow SSH with a one-time-pad plus ssh public key auth.

Just to be nitpicky, two-step authentication is not two-factor authentication, more like 1.5 factor, as it is still two items that you know. That you must have the phone is not strict as only the content of the message is required and not something generated by the phone.Of course, it is good enough protection for mainstream, but a directed attack to a specific target, will look to compromise the phone.

Just to be nitpicky, two-step authentication is not two-factor authentication, more like 1.5 factor, as it is still two items that you know. That you must have the phone is not strict as only the content of the message is required and not something generated by the phone.Of course, it is good enough protection for mainstream, but a directed attack to a specific target, will look to compromise the phone.

Also to be nitpicky, if you have someone who has acquired your primary password and is setting themselves up to compromise your phone, you have bigger problems than the standard "$COMPANY got their database hacked!" problem.

I'm beginning to think we need a standard Authenticator implementation, though. Any reason not to just use Google's Authenticator for everything? I'm already up to four separate apps :-/

I turned this on yesterday and you can use Google's Authenticator. In theory, you should be able to use whichever you want as long as it supports OATH.

You can use google's implementation for OAuth's HMAC one-time-pad on any PAM-enabled service (read: anything that runs on linux somewhere). Just search for "google authenticator $FAVORITE_LANGUAGE" for an implementation. It's really a simple and clear standard.

I just turned on 2-step for SU'ing on a server here as an experiment. Wow! I'm kinda tempted to tell people that we'll only allow SSH with a one-time-pad plus ssh public key auth.

I'm with Xoa, though. I would like a token separate from my phone that can be a factor to multiple auth systems. If I still played SWTOR or WoW, I'd potentially have 4 tokens, not including the ones from my bank and CC of which I haven't availed myself. 6 tokens is a damned annoying key ring.

Boskone, check out that github link. It's a simple python script to make the one-time keys. You could put it on anything with a bit of logic and an accurate clock. (arduino in your back pocket?) Your cellphone is just a convenient Turing-complete widget that tends to be nearby.

The Google Authenticator App can hold as many login pads as you want, not just google ones. It is really a general-purpose app, not a special google thing.

You can also print some immortal (but one-time use) codes and put them in a safe or in your wallet (if you don't tend to lose it often).

Just to be nitpicky, two-step authentication is not two-factor authentication, more like 1.5 factor, as it is still two items that you know. That you must have the phone is not strict as only the content of the message is required and not something generated by the phone.Of course, it is good enough protection for mainstream, but a directed attack to a specific target, will look to compromise the phone.

I can only hope this is the start of a wave of corporations (So far Google, Steam, and Dropbox showing themselves to be good corporate citizens int his manner at least) making it possible for consumers to engage in better security practices, since many of these businesses have show themselves unable to keep our information safe. Although I realize that possibly for hacking is never zero, when using two factor authentication with a unique secure password kept in keepass or lastpass, I think the amount of vulnerability your average consumer has drops to a reasonably low level.

Yah but it can be taken too damn far. I want to write a nastygram to steam when I loose the cookie on my browser and have to wait 10 minutes for them to send me an e-mail so I can THEN sign into my system.

And don't even get me started on battle.net. U want to kick someone's ass at blizzard. I sign in from a different IP address range. Not even if its the same computer, with the same password, with the same God damn pin generated from the Android two factor authentication and it STILL throws up a red flag, and forces me to reset my password. There is such a thing as taking security too damn far.

And don't even get me started on battle.net. U want to kick someone's ass at blizzard. I sign in from a different IP address range. Not even if its the same computer, with the same password, with the same God damn pin generated from the Android two factor authentication and it STILL throws up a red flag, and forces me to reset my password. There is such a thing as taking security too damn far.

You do know that BNet got compromised recently, and everyone has to reset their password? Normally, password plus authenticator code is enough to get you in, even on a new computer.

And don't even get me started on battle.net. U want to kick someone's ass at blizzard.

Bnet has to have the code 8 digits long, when people(T) have an average short term memory of 7 items. God-forbid having any separator in the key, which you have to fumble through holding your phone while keyboarding. The rotation clock is too short, I always have to wait for a fresh one. Since half the key is something generated from your app, you can put the authenticator on anywhere from zero to one devices. This half key has nothing to do with keeping the secret less stolen in some "hypothetical" Blizzard hack, it's just there because Blizzard cannot fathom someone owning a phone and a tablet.

Google's 2-factor system is great, Blizzard took the same idea and tuned it to be nearly as secure (save one teeny hack), but instead far more annoying. The only change that would bring me back for another Blizzard title would be them being bought by Steam (or while I'm dreaming, CD Projekt).

It took me about an hour yesterday to get this set up. And it wasn't even Dropbox's fault.

Using Google Authenticator on my iPhone, Dropbox kept rejecting the codes the app spat out. Eventually I noticed that my iPhone's clock was about two minutes ahead of my PC's clock.

Turns out I had set the iPhone to manual time setting a while back, when I noticed that the automatic setting kept tossing me into the wrong time zone*. But on manual, after three or four months my phone will deviate by a few minutes, which is enough to render time-based tokens on Google Authenticator useless.

Moral of the story: if you're having issues, make sure your phone's time is accurate.

*I am in Brisbane, Australia, the automatic setting keeps going to Sydney, Australia. Only a small problem because Sydney observes DST, Brisbane doesn't.This is a fairly known issue that seems to happen on all Australian carriers, but between the carriers and Apple themselves, someone is being a retard. The only suggestions I got were 'Speak to Apple" (my carrier) and 'Restore your phone' (Apple).

It's more than a little annoying that Matt Honan's experience is being invoked in these articles about better user authentication -- that's a bit like blaming the victim, isn't it? The weak link was not the user in his case, it was Amazon's and Apple's inane policies of allowing over-the-phone account changes and password resets without requiring any of the security precautions (like secret questions) that had been established. While two-whatever authentication may be (and I'll reserve a whole lot of judgement on whether it actually is) a good idea for average users, it certainly wouldn't have prevented the scariest actual damage that Matt suffered, the loss of his laptop's hard drive's contents. That only required that the hackers got access to his iCloud account, which only required the screw-ups at Amazon and Apple. Turning on two-factor Google account authentication would only have prevented the hackers from getting into his Twitter account, and all they could do there was embarrass him for a little while. The bottom line, as always, is that any security is only as good as the people guarding the gates.

It's more than a little annoying that Matt Honan's experience is being invoked in these articles about better user authentication -- that's a bit like blaming the victim, isn't it?

The bottom line in authentication security is that you have to take responsibility for yourself, because nobody is going to do it for you, nor can they even if they wanted to. While in that case Apple definitely screwed up, he could have prevented it all himself by having better personal security, and using the tools available to him.

It's more than a little annoying that Matt Honan's experience is being invoked in these articles about better user authentication -- that's a bit like blaming the victim, isn't it?

The bottom line in authentication security is that you have to take responsibility for yourself, because nobody is going to do it for you, nor can they even if they wanted to. While in that case Apple definitely screwed up, he could have prevented it all himself by having better personal security, and using the tools available to him.

No, he absolutely could not have.

If you've actually followed what happened to him, the compromising of his iCloud account and wiping of all his devices occurred entirely because of terrible security policies among the telephone customer service reps at first Amazon and then Apple. He should obviously have had current backups, but that would only have ameliorated the fallout of the hack. Absolutely nothing that was in his control in any way could have prevented Amazon and Apple from allowing his accounts to be so easily compromised in the first place.

My concern here is two-fold. First, if we don't keep holding Amazon and Apple responsible for their bad policies, what motivation do they have to improve them? If so many of the articles published in the wake of this incident blame the victim rather than the actual parties at fault, then the media is providing cover for the bad behavior at these companies to continue. It's a subtle use of the fear, uncertainty, and doubt principle (though I'm not proposing that Amazon or Apple are actually encouraging these articles, the effect is the same as if they were).

Second, pushing average users into more onerous security measures that would have provided absolutely no protection in the case that is being cited amounts to nothing more than security theater. Users will get the warm fuzzy feeling that they are taking action to protect themselves when in truth, unless Amazon and Apple drastically change their procedures, hackers can continue to use these exact same vulnerabilities anyway.

If you've actually followed what happened to him, the compromising of his iCloud account and wiping of all his devices occurred entirely because of terrible security policies among the telephone customer service reps at first Amazon and then Apple. He should obviously have had current backups, but that would only have ameliorated the fallout of the hack. Absolutely nothing that was in his control in any way could have prevented Amazon and Apple from allowing his accounts to be so easily compromised in the first place.

If he had a google authenticator on his gmail account, the hack would have stopped dead there, because they wouldn't have been able to compromise the email, which let them take over everything else. The hacker himself told him that. Check your facts.

Quote:

My concern here is two-fold. First, if we don't keep holding Amazon and Apple responsible for their bad policies, what motivation do they have to improve them?

They definitely should improve them, but you can't trust that every single company you interact with is doing the right thing. You just can't, it's not realistic.

Quote:

Second, pushing average users into more onerous security measures that would have provided absolutely no protection in the case that is being cited amounts to nothing more than security theater.

Entirely false. There is no security theater about using strong passwords and two factor authentication. The goal is not to make your stuff hacker proof (which is impossible), it's to make your stuff so much trouble to crack that the hackers and criminals move on to someone else. Two factor authentication, unique long passwords, and being informed all help you protect yourself, because nobody else is going to do it for you.

If you've actually followed what happened to him, the compromising of his iCloud account and wiping of all his devices occurred entirely because of terrible security policies among the telephone customer service reps at first Amazon and then Apple. He should obviously have had current backups, but that would only have ameliorated the fallout of the hack. Absolutely nothing that was in his control in any way could have prevented Amazon and Apple from allowing his accounts to be so easily compromised in the first place.

If he had a google authenticator on his gmail account, the hack would have stopped dead there, because they wouldn't have been able to compromise the email, which let them take over everything else. The hacker himself told him that. Check your facts.

Wow, just wow. You might want to read the timeline of the hack just a bit more carefully before you spout off about how I should check my facts! Here's a hint: scroll down to the paragraphs beginning with "At 4:33 p.m."

Willful ignorance has really become something some people are truly proud of, I guess.

Oh, and thanks for making my point for me about how all these FUD-spreading articles have convinced people that the real problem is a lack of more two-factor authentication... Security Theater at its best!