Dropbox Password Goof Let Any Password Work For 4 Hours 185
tekgoblin writes "Dropbox confirmed today that for some time yesterday, any user's account was accessible without a password. The glitch was a programming error related to a code update and accounts were only vulnerable from around 1:54 pm PST to 5:46pm PST." "Only" is relative; as reader zonky puts it, "It took around 4 hours from deployment for Dropbox to notice they'd entirely broken their authentication scheme."
Regression testing (Score:5, Informative)
Re:Regression testing (Score:5, Funny)
This is why automated regression testing is a best practice. I guess Dropbox don't test their authentication.
That would be so oldschool. We do agile development now, and the user is the tester once the unit-tests pass.
</sarcasm>
The Most Interesting Developer In The World (Score:5, Funny)
I don't test my code. But when I do, I do it in Production,
Re: (Score:2)
Saw this on one of the more amusing github comment threads [github.com] of recent times.
Re: (Score:2)
Re:Regression testing (Score:5, Funny)
Re: (Score:2, Funny)
snap!
Re: (Score:2)
You mean that someone has finally closed the sarcasm tag on Slashdot?
No wait, must be nested a few deep.
Backdoor for feds? (Score:2)
My best guess is the feds took the opportunity to check dropbox.
Re:Regression testing (Score:5, Informative)
No, they have never claimed that the password was involved in the encryption they use - they use one single encryption key for all data stored. Their terms of service did say that your data is inaccessible without your password, but this is nothing more than permissions rather than per-account encryption.
There has been lots of valid shit thrown around about Dropbox over the recent weeks, but please do try and get stuff right before you complain.
Re: (Score:2)
Their terms of service did say that your data is inaccessible without your password, but this is nothing more than permissions rather than per-account encryption.
Or it could be that a personal encryption key is stored in their user profile database. So all data is still uniquely encrypted per user, but access to the key is available to the admins (and as you indicated limited by process/permissions).
I would hope that every person's data is not encrypted with the same key. If that's the case, then they may
Re:Regression testing (Score:5, Informative)
Again, no - its been well documented that Dropbox does global deduplication and single instance storage, across all data in their database. That would not work anywhere near as well for them if each account used its own encryption key - until they turned it off recently due to abuse, you could shove an Ubuntu iso into your local Dropbox and have it "synced" 100% in seconds, as the Dropbox servers realise that they already have it in their global pool, and simply tell your client not to upload it.
So yes, they use a single key.
Re: (Score:2)
Again, no - its been well documented that Dropbox does global deduplication and single instance storage, across all data in their database. That would not work anywhere near as well for them if each account used its own encryption key - until they turned it off recently due to abuse, you could shove an Ubuntu iso into your local Dropbox and have it "synced" 100% in seconds, as the Dropbox servers realise that they already have it in their global pool, and simply tell your client not to upload it.
You know, if it wasn't for copyright trolls and whatnot, that would actually be a pretty damn good feature.
Re: (Score:3)
It should be possible to do global deduplication while still using encryption. You'd need to store (unencrypted) hashes of the files stored though.
What you typically do is encrypt a block with a random session-key, then you encrypt the key with the users public key, and store both. (the encrypted block, and the encrypted session-key), the legitimate user then retrieves the encrypted session-key, decrypts it with his private key and uses that to decrypt the encrypted block.
With this scheme, there's nothing s
Re: (Score:2)
That only works if you know ahead of time which users will need any given block, and of course you don't.
If user 1 uploads file A, and you encrypt it and store the key encrypted with user 1's key, and then user 2 uploads file A too, you can find out that the data is already uploaded by user 1, but you can't actually find the key to that data to give to user 2.
Re: (Score:2)
what if you where to use user key's to encrypt the block chain info? you could keep the blocks unencrypted (or all using a different but single key) but without the users key you would be able to assemble the file for that user.
The only downside i see is global block/orphan cleanup.. with the chains encrypted they wouldn't be able tell who would still be using a block and like wise when no one is using the block..
Re: (Score:2)
*bad form to reply.. but just thought about it and if you assigned a counter to a global block you could use it to know when it is no longer used (blah the obvious).. so yea what would be the problem with just encrypting the block chain with a user key?.
Re: (Score:2)
Good thinking ! But there's a fairly simple way around that. What you do is the following:
Person 1 uploads file A, you store hash(A), encrypt(A, randomkey), encrypt(randomkey, public_key_of_1)
Person 2 uploads file A, and as you correctly point out, at this point we're unable to find the randomkey used to encrypt that file. But we don't need it, we can do this instead:
encrypt(new_A, new_randomkey) store this block instead of the previous encrypt(A, randomkey). Now we know new_randomkey and can store both enc
Re: (Score:2)
Yes, but I think a large part of why they do this is because of the bandwidth savings.
Re: (Score:2)
Re: (Score:2)
Only good if someone hacks in the FS remotely, steals a backup tape, or finds a discarded drive from their SAN.
Right, and it's not as if anyone has ever managed to hack into a major companie's server [wikipedia.org].
This is the last straw for me. I'm not going to use DropBox ever again. Clearly whoever's in charge of their security is not doing a good job.
Re: (Score:2)
Re: (Score:3)
The processing power is not the issue, the storage is. They can't do global dedupe on the block level if they use per user encryption.
Re: (Score:2)
Re: (Score:2)
This only protects from other non-privileged users. If the service stores the key, why bother with the encryption? If you hash to check for dedupe you can check who has what files, again why bother with encryption in that case?
Re: (Score:2)
Re: (Score:2)
Who says that matters?
If I have a list of hashes I know who has what files.
If the provider does the encryption they have the keys and any privileged user there can decrypt.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
TrueCrypt. Free. Easy to use. It is even recommended by the DropBox FAQ, IIRC. Or something like it. Relying on a third party to keep your private data private is a fools game. While I'd like *some* standards (i.e. this epic fail is not excusable), I can't lay the task of keeping my stuff safe on someone else.
Re: (Score:2)
Well, gee, that makes me feel good about their security...
Re:Regression testing (Score:5, Insightful)
I've never treated Dropbox like it's secure. It's convenient for copying around files, but I wouldn't use it for anything sensitive.
I think if you're aware of the fact that it's only *slightly* more secure than a public folder on a shared network and use it accordingly, you can still make use of Dropbox as a tool. Although, admittedly, my usage of it has diminished since I initially got it.
Re: (Score:2)
the fact that it's only *slightly* more secure than a public folder on a shared network
Holy exaggerations, batman?
Re: (Score:2)
Yeah, it's not like anyone can access anybody else's files!
I mean, not any more.
Not until the next time they break it, anyway!
Re: (Score:2)
In terms of the level of trust I apply to them, not at all.
First off, everything is "in the cloud", which means you don't really know where it is and who has access to it. Second, this isn't the first security issue they've had. And, finally, they've pretty much admitted that if law enforcement comes knocking, they'll hand over your files.
From the get-go I've been fairly convinced that their stuff was weak security at best. Were you of the impression that the security they have
Re: (Score:2)
How about testing? (Score:3)
Doesn't a service like that have a preview deployment where they can properly test it? Maybe some automated testing for their authentication system, which I believe is a pretty big part of what they're doing?
Alas, testing is much like security, in that many companies try to get away with as little as possible.
Re: (Score:2)
Re: (Score:2)
That is exactly the kind of thing you do need to test: not just whether correct passwords are accepted, but also whether wrong passwords are rejected. Automatic testing is all about edge cases like these.
Re: (Score:2)
Re: (Score:3)
Automated authentication testing that doesn't test using the wrong password?? Must have been brought to you by people who took the short bus to Q/A training...
Password Strength (Score:2)
Password strength is great, but this does go to show that no matter how many locks you put on your front door, if someone else forgets to close it, you're still going to lose your television...
Re: (Score:2)
I just wonder what kind of things people stored there they wouldn't want to get around the internet... that might now be getting around the internet.
Re: (Score:2)
I recently read an article that explained how DropBox was perfect to share your KeePass database among all your devices. I've also heard of BitCoin wallets.
Re: (Score:2)
I recently read an article that explained how DropBox was perfect to share your KeePass database among all your devices. I've also heard of BitCoin wallets.
Well, your KeePass database is protected by its own encryption, and its security depends on the password that you choose for it. Not something I'd want on the Internet, sure, but it's not completely naked. If you use the key file for authentication, along with a password, and don't replicate the key file, you're probably okay.
Re: (Score:2)
Well, in the KeePass case, it's still encrypted. After gaining access to it, they'd have to brute-force your (hopefully good) password.
Of course, if you use Dropbox to sync TrueCrypt volumes, then you have a *second* key that needs to be broken.
Re: (Score:2)
Do you use Dropbox with Truecrypt volumes? If yes, how large are your encrypted images? Is it practical?
I mean - if you change something in the image - Dropbox will have to upload the entire file... so I'm not sure this works well with big images.
Re: (Score:2)
Do you use Dropbox with Truecrypt volumes? If yes, how large are your encrypted images? Is it practical?
Yes. Several gigabytes. Yes.
I mean - if you change something in the image - Dropbox will have to upload the entire file... so I'm not sure this works well with big images.
Not true. They do block-level updates (or at least they have for some time; there was a time when they didn't support TrueCrypt volumes but they have for a while now). A single change in a TrueCrypt volume only affects the block in which the change took place (otherwise large images would be impractical if it had to re-encrypt the whole image for a single change). Dropbox detects this change and syncs only the changed block.
Re: (Score:2)
Yep. In fact, one possible explanation for the $500,000 bitcoin heist of a week or so ago was that the affected user kept his wallet on Dropbox. (There are other possible avenues through which he could've been hacked of course.)
Re: (Score:2)
Storing stuff you don't want on the internet, with a service you access via the interent is moronic. At the very least upload only encrypted blobs.
Re: (Score:2)
Don't forget because (in theory) an attacker has unfettered access to the encrypted blobs, use a keyfile and not just a passphrase. This way, an attacker has to deal with the full keyspace.
Say I have a number of documents at college I'm working on. I use a cryptographic token that stores a TC, KeePass, or AxCrypt keyfile that is randomly generated. This way, the data residing on the remote server is not just protected by a sturdy passphrase, but will require access to something that is stored on a physic
Fire the programmers please (Score:2, Insightful)
Re: (Score:2)
Chances are they enabled a function to impersonate any users in order to validate that it was working properly without having to know someone's pwd. Problem obviously is that they kept the original config. Deployment team, testers or devs probably share the problem equally. Most likely someone forgot to document all the steps including re-enabling the authentication piece.
Re: (Score:2)
I seriously doubt it was an error in "knowledge of authentication", it was a mistake in the implementation. Programmers should not do anything beyond simple unit testing on their own code, and certainly shouldn't be wasting their time doing regression testing, which should be an automated function and any manual testing done by a separate team. If anything, it is the testers that should be fired, but why fire the one bunch of testers who are probably never going to make this mistake again?
Re: (Score:2)
If programmers lost their heads whenever another programmer was upset with their work, there would be no programmers left.
Re: (Score:2)
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization."
Re: (Score:2)
What would be cool is if DB offered more than just password based authentication.
What would be cool would be client certificate based authentication, perhaps generated on a purchased cryptographic token from DB. Accounts can have more than one token for recovery reasons. This not just allows for authentication, but encryption of data. The only way an attacker could decrypt stored data would be to physically gain possession of a token and know its PIN (or guess it in less than 3-17 tries before the device
wrong kind of thinking (Score:4, Insightful)
Re: (Score:2)
So you never make simple stupid mistakes? If you do, should you be fired immediately for them?
Depending on the severity of the mistake firing someone might be the best course of action. Personally, I agree that something of this magnitude is sackworthy.
Re: (Score:2)
This is going to cost DropBox in terms of reputation, customer retention, and future customers.
I know I have made my fair share of mistakes, but someone has to bite the bullet for this gross oversight.
Re: (Score:2)
Re: (Score:2)
I remember someone told me a story about someone making a huge mistake that cost the company millions. When an exec was asked why the guy wasn't immediately fired he said, "Why would I fire him? I just spent five million dollars teaching him not to make that mistake again".
The point is, you fire someone, you then have to hire someone new. You would hope that the new person would not make the same mistake. You might hope that a mistake that costs your company millions is so obvious that no one else could
Re: (Score:2)
p>Make the responsible programmer clear up each and every problem which his mistake caused, but don't sack him.
How do you propose the responsible programmer "clear up" all the data that may have been downloaded and convince users their data is still safe?
Let me summarize every comment that will appear: (Score:2)
1. Open source or GTFO
2. Cloud is dangerous; this is why cloud fails
3. I like dropbox
4. Stop with the dropbox spam.
Re: (Score:2)
I don't trust freemium services like this with important things.
If I'm trusting my private data to a company to store, or anything else equally important, I have no problem paying for it, and I don't want to share the service with a trillion and one freeloaders on the Internet that are going to divert my subscription fees away from... well, making sure stuff like this doesn't make it into
Re: (Score:3)
If I'm trusting my private data to a company to store
Then we can safely dismiss your comments as the ravings of a fool.
If you want to see what all these companies think of your private data, look at their SLAs. Do they offer anything more than subscription fee back in case of leak or loss?
Re: (Score:2)
What about if the company goes bankrupt? SLAs mean zilch then, and all privately stored data can be put on a torrent for anyone to download, and there is nothing anyone can do to stop that.
I'll be blunt: I hate calling for regulation. However, here is my proposal:
Have a status of "trusted storage provider" which is a certificate by the US government and led by a body. Essentially for a business to get this status, they pay a deposit, submit to security checks (physical, network based, etc.), and have a
Re: (Score:2)
What about if the company goes bankrupt? SLAs mean zilch then, and all privately stored data can be put on a torrent for anyone to download, and there is nothing anyone can do to stop that.
Bankruptcy DOES NOT WORK THAT WAY. Doing that would expose the people doing that to lawsuits.
I like you idea, but would prefer stronger labeling laws and enforcement to more regulation. This is because the regulation would mean nothing eventually.
Re: (Score:2)
What lawsuits?
Take an average server. It belongs to the cloud provider, and clients store their data using the server as a head, and the backend SAN for the actual storage. The cloud provider tanks. The server and its SAN are auctioned off because the company is in receivership.
Mallory, the purchaser of the machine finds that there is a bunch of stuff including PII on it. He doesn't like the old company, so creates a torrent, and seeds it.
Can you sue Mallory? Nope. He just bought some computer hardwar
Re: (Score:2)
The machines are wiped before auction, otherwise the auction company and the seller are on the hook. Used hardware is pretty common in the server room.
Fixed in five minutes? (Score:2)
We discovered this at 5:41pm and a fix was live at 5:46pm
My guess is they updated to a working version. It would be unsafe to deploy a fix in five minutes anyway. Potentially making the problem worse.
Re: (Score:2)
On a wild guess, I'd say a developer commented out some critical authentication code for testing, it somehow pushed to production and the fix was a simple "OMG turn that back on" - five minutes sounds about right for restoring a good version.
Re: (Score:2)
Either that, or say... using "+" instead of "." to concatenate the assword and seed string on PHP: In the former case, you'll simply get out 0 for(most) any string input, which would end up allowing any password to create the same hash.
And yes, I know from personal experience on that one... Too much Python previously that day.
Re: (Score:2)
Unless its the proverbial
echo ENABLE_AUTH=YES >> /etc/rc.conf
Relax, it was only 4 hours. (Score:5, Funny)
Relax Mr. President, We only let our enemy control our nuclear arsenal for four hours
Relax Japan, we have enough battery backup for the cooling system for four hours
Relax Gulf Residents, it's only been spilling oil for four hours
Relax Public, the serial killer has only been escaped for four hours
Relax Columbine Parents, the killing spree and stand off only lasted for four hours
Re: (Score:2)
Relax Mr. Sys Admin, the hacker has only been downloading your database for four hours.
Relax Mr. Homeowner, your house has only been burning for four hours.
Relax Facebook users, your information has only been sold off for four hours... errr... years.
Relax Mr. Necrophiliac, she's only been dead for four hours.
Re:Relax, it was only 4 hours. (Score:5, Interesting)
but fortunately there is no evidence of any unauthorized access.
Of course not, all the access where authorized by the faulty authorization system.
Dropbox's followup is no good (Score:4, Insightful)
Not only was there a serious security issue here, but Dropbox customers are having to find out about this through blogs. Dropbox has yet to email its users about this issue. It claims on its blog that users who logged in during this time have been notified. I logged in during this time, and have received no notice.
I am now leaving Dropbox. I need to review Wuala and Spideroak to see if they meet my needs, but I can safely say that this event and Dropbox's earlier behavior has demonstrated to me that they do not take the security and privacy of their customers seriously.
Re: (Score:2)
I used to use SpiderOak for backups on Linux, but gave up when it failed in two different cases to backup all the files I'd asked it to, and to restore them. It was also incredibly memory heavy so it ran badly on a 1GB RAM PC.
It might have improved but I always found the user interface highly cryptic.
Re: (Score:2)
You might be interested in CrashPlan [crashplan.com]. Works on Windows, Linux, Mac OS X, and Solaris. After I had my laptop get stolen I had no problem restoring ~50 gigabytes of data.
It's not really a Dropbox-type service, but it is useful as a backup software/service.
What Else Did They Do? (Score:2)
Was there any sort of check down after-the-fact to ensure that improper logins were terminated / any changes rolled back?
Re: (Score:2)
They terminated all sessions to force users to log back in - and Dropbox staffers are always approachable to roll back accounts to a point in time, so if you need to request a roll back due to third party activity you just need to log a support ticket.
I'm guessing they don't have a log of which sessions were illegitimate, as that would require storing presented usernames and passwords and having the ability to recheck them at a later date, so an automatic roll back of any changes would not be on the cards h
Re: (Score:2)
So what magic do they use to rollback the breach of your privacy?
Professional Code: Secure Pre-Flight Testing? (Score:2)
Somehow with a major break-in or other fault appearing virtually every day in the news, I am beginning to think large operations just don't have the required level of professionalism and funding of a proper testing environment (software & hardware) to get things right before they roll out the code publicly.
The prior news story which made me roll my eyes was the airline which lost use of some of its computers and stranded passengers.
Re: (Score:2)
Funding? It's the simple "Schneier principle".
As long as companies are not really responsible (financially) for any of their security failures, they will not invest in security.
No cost? No risk.
Re: (Score:2)
Somehow with a major break-in or other fault appearing virtually every day in the news, I am beginning to think large operations just don't have the required level of professionalism and funding of a proper testing environment (software & hardware) to get things right before they roll out the code publicly.
The prior news story which made me roll my eyes was the airline which lost use of some of its computers and stranded passengers.
Alternately, it might be the case that getting security right is actually really, really hard when you have teams of very smart people dedicated to breaking it. Which isn't what happened in this case, but could just as well have been.
There's a reason everyone bitches about having to jump through hoops to pass, for example, a PCI Level 1 security audit. There's a reason that in most breaches its found out that there were practices that violated their PCI (or HIPPA, or insert-standard-here) customary and ex
Honor system (Score:2)
"Hi, welcome to Dropbox! Please follow the honor system, and do not be nosing about in others' things, or you'll have to sit in the Time-Out Chair."
Seriously?
[On another note: This should never be any worse than losing a thumb drive. If folks are using their own encryption on their important stuff, and blow the dust off their backups from time to time, it's no big deal. Unless you're one of those folks who doesn't do those things, in which case you should also go have a Time-Out.]
Vindication! (Score:2)
Stuff like this
Re: (Score:2)
I use it for the ease of keeping a few files synced between my desktop and laptop that's rarely turned on since I'm not traveling as often. As to security, what I sync doesn't need it and it's no great loss if the shit gets spread all over the web because all it is is notes on things like some online games I play on Neopets and garbage like that. Nothing important and who cares.
Simple release mixup (Score:2)
It wasn't strictly a bug in the code, they just accidentally put the FBI version up on their main web servers instead of just on the secret back door servers that all cloud based services have for government access.
The image in my head of Dropbox (Score:2)
Right now I'm imagining Dropbox being like a really small company, with a PHB manager, and all the code being worked on by one overworked and underpaid guy fresh out of college who has to do all the testing himself, while the PHB is constantly breathing down his neck for him to finish. These are the places that usually create such epic screwups.
For a moment I thought of Citibank being the same way after their URL hack came to light (except with their programmer being terribly incompetent on top of overworke
Dropbox - because vanilla FTP wasn't bad enough (Score:2)
Re: (Score:2)
How can you fuck up something worse than a system devised back when nobody on the net really cared about security?
That's easy - remember when the SSH.com daemon (3.0, IIRC) would accept any two letters as a valid password?
Trust the Cloud? (Score:2)
Data exposure isn't the only consequence. (Score:2)
Ah, that explains it (Score:2)
I wondered how "Mad Dog 20/20" got on our grocery list.
Re: (Score:2)
Doesn't this mean that none of the data on their servers is truly encrypted in any way?
No, it doesn't. All it means is that the encryption key is separate from the password. This is probably a good thing. You don't want to be decrypting gigabytes worth of data and then re-encrypting it every time a user changes her password. Also, customer service wise, you want to be in the position of being able to say "You forgot your password? Sure, we can still recover your data." rather than "You lost your password? Nothing we can do about it. Sucks to be you, I suppose."
So instead of DATA=DECR
Re: (Score:2)
wooohaaaaaa
Re: (Score:2)
gv dsgasdgsadg
Re: (Score:2)
slowdown cowboy