RFC 6238 TOTP: Time-Based One-Time Password Algorithm describes how to implement your own google authenticator if you wish http://tools.ietf.org/html/rfc6238
The one thing I'm missing from this thing is to be able to export the data. Migrating from one device to another is painful as it is..
Edit: I was annoyed so long by this missing feature and - never did something myself. My bad.
If you have the same problem (one device paired with a couple of services, you want to migrate the accounts):
'/data/data/com.google.android.apps.authenticator2/databases' contains the sqlite3 file 'databases', which contains a table 'accounts' with your keys (and counter values, if necessary).
A password as secure as my phone is not promising; T-Mobible was recently happy to reset my lost PIN by having me give the last four digits of any phone number I'd dialled in the last 23 hours. I don't really think it's as useful two-factor because the token is only as secure as another company's password system. (Aside from the problems that you have to have a Google Account and a smartphone.)
I looked into this recently when Dreamhost launched google-authenticator instead of two-factor auth. Disappointing.
Someone would need to not only have possession of your phone, but your password as well. So for a hacker to work this:
First, get your password. Second, find your location. Third, steal your phone, which for most people, is almost always on their person. Finally, crack whatever security mechanism you have on your phone.
For someone to go through all that trouble ... you must be storing some very valuable info. If that's the case, may I suggest that Dropbox is probably not the right platform? In fact, any internet connected platform is probably not the right answer.
No. First, get password. Second, get phone number. Third, pretext to gain control of the account and forward/copy texts, view them via web interface, or replace the phone.
The point isn't the security mechanism, but for consumer products the point is physical location. Without two factor authentication, a sweat shop in China could hack you (and thousand others) easily. With two-factor authentication they would need physical proximity to you, so they won't even try.
What about emails that are sent from services like Campaign Monitor and the like? There's almost no way to know where that link's going to end up because of the 'tracking middleman' that they all have setup.
Good, solid response to the intrusion. I'm particularly happy about the two-factor opportunity. I have no problem re-authenticating every 60-90 days with an SMS sent to my phone, and _definitely_ want any new system to be two-factored before having access to my Dropbox.
The only issue is that a lot of programs (mobile apps, especially) seem to interact directly with the Dropbox API, which leaves no possible interface for a secondary authentication. Google gets around this by having app-specific passwords that you can generate and de-authenticate at will; it'll be interesting to see how Dropbox handles it.
"A stolen password was also used to access an employee Dropbox account containing a project document with user email addresses."
I see two ways to read this.
a) An employee happened to have a personal Dropbox account, and it was that personal account that was hacked, in exactly the same manner as the other accounts referenced. The employee probably used a different password on Dropbox's internal systems, and as a result there was no internal breach.
b) An employee account for an internal Dropbox system was hacked, and this internal account allowed the attacker to access the project file. In this scenario, even though Dropbox made no specific comments to this effect, we can assume that the attacker may have obtained access to Dropbox's internal networks, so who knows what they could have made off with.
It makes a huge amount of difference to me which of those two readings actually took place. In scenario (a), this all boils down to users (including one particular employee) using the same password on too many sites. In scenario (b), Dropbox could be hiding a much larger breach.
Presumably because they dogfood their own product to their employees. I don't actually know if they do that, but I do know a lot of other companies that do. And it makes sense--if your employees don't use your product on a regular basis, then you're in trouble. But apparently keeping company data in a Dropbox account (personal or otherwise) also has potential security implications.
This is why I'm disappointed that end user open source software is in such decline right now. These kinds of "long tail" user needs will never be met by the proprietary software world. Well, this particular one might, but for every need that gets implemented, 10 more obscure needs will spring up behind it.
Dropbox is making fistfuls of money, and, like all proprietary software companies, they need to stay focused to maintain momentum.
Although it might not feel like it to most people, I think we're in still in the dark ages of software. Not quite as dark as the Microsoft era, but dark nonetheless. We just don't have the tools, infrastructure, and culture necessary for open source to really be a viable space for the typical, scattered programmer to spend their time. I'm optimistic that will change, but I'm not sure how long it will take.
Because where are you going to put it on the other computers? So far dropbox has decided it's not worth the complication.
What you want is two clicks plus a confirmation popup and/or wizard. Moving a folder and making a shortcut is two drags and one extra click. It's not a big deal.
Same here except the feature I am waiting for is a full featured Android client ie sync all files to the local Android device filesystem (with the option to only sync when connected to Wifi).
I really hope they don't make 2fa mandatory. I hate most 2fa systems I've seen (I use Google Authenticator for one gmail account I have, and it makes life even more of a pain than it needs to, even just on Google properties). Having to reauth ~6 devices every month is obnoxious, and I already have a perfectly good password manager with long random per-site passphrases, plus secure storage of my key file and a strong memorized passphrase for it, unlocking sets of passwords only on certain machines. 2fa, particularly a naive version involving SMS or telcos, would make my security worse.
> In some cases, we may require you to change your password. (For example, if it’s commonly used or hasn’t been changed in a long time)
This is ambiguous...by "commonly used" do they mean 1) I'm logging in with my password frequently or 2) my password itself is a commonly used password? I'm assuming (and praying!) they mean the former since the latter would mean they're storing my password in plaintext.
UPDATE: Dropbox doesn't store in plaintext. I was incorrect to assume these were the only two possibilities. Confer child comments.
It's quite obvious from context that it's the latter. However, there is zero implication that they are storing passwords in plaintext. There are several ways to implement such a feature.
First, the password could be checked on login when it is sent in plaintext but not stored. Second, they could run an offline dictionary attack against the hashed password database.
Given they state that some accounts were compromised by stolen passwords from "other websites," it would make sense to run some sort of dictionary attack using lists from those sites.
It wouldn't, necessarily -- I thought about this a little, and there are ways to identify commonly used passwords without storing them in plain text.
They could check passwords on login (before salting/hashing) against a blacklist of 'commonly used passwords'. This is probably the most secure method, as it only implies that users passwords are not on the blacklist, but does not imply plain text storage or unsalted hashes.
If they were not salting their hashes, then they could query their database for hashes that match the hashed version of commonly used passwords. Similar to the blacklist above, but implies that the passwords are stored unsalted, which is sad.
There are many different ways to salt and hash, some more secure than others (bcrypt and DES crypt() being two examples with vastly different levels of security).
They wouldn't have to store your password in plaintext to determine that. They could just hash commonly used passwords and compare the hashes to yours.
A little bit of googling makes it seem like auth tokens are not sent it plaintext over HTTPS but are authenticated using challenge response – http://forums.dropbox.com/topic.php?id=47952 The WWW site may differ.
Obviously that would work, but not if you're using Challenge-response authentication. In general, I don't think people bother with now that when using https.
Assuming they use straight up salted sha256, my five year old core2 laptop does at least 10,000 per second, per core. They could check every user for the top 10k passwords for a few hundred bucks of EC2 time.
I'm curious who all received this email? Was it sent to the entire user base? If not, what selection criteria did they use?
Everyone I've talked to seems to have received the "reset your password" email. I'm quite curious because I'm certain (up until now) that the password I used for Dropbox was both (a) not commonly used and (b) had been changed recently and (c) not leaked anywhere else (to the best of my knowledge).
I also received the reset email and my password for dropbox was a random string generated by lastpass so I'm fairly confident that it wasn't leaked elsewhere. I wouldn't be alarmed if you got the email.
One of the more glaring security issues with Dropbox, is the way they are handling 3rd party integration.
Giving full access to some random new startup or app is NOT cool. Sure I don't have to, but people also like to try new stuff, and the integration is half the reason for using cloud services in the first place.
In fact this really applies to all 'platform' plays facebook, linkedin etc. Rather request minimum priviledges to inter-operate or authenticate, rather than sweeping authorizations.
When are email addresses going to be considered something that should be protected as well. Obviously you can't one-way hash these, but you can secure them, and definitely not leave them in project documents.
Good question, but perhaps it's shorthand for "your password generates a hash matching that generated by passwords found in various stolen password lists in circulation".
http://code.google.com/p/google-authenticator/
Their "Such as" example makes it seem they only decided to use 2-factor but haven't chosen an implementation yet.