Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Dropbox Password Goof Let Any Password Work For 4 Hours

timothy posted more than 3 years ago | from the you'll-find-we're-very-open-minded. dept.

Cloud 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."

cancel ×

185 comments

Sorry! There are no comments related to the filter you selected.

Regression testing (4, Informative)

Bogtha (906264) | more than 3 years ago | (#36510846)

This is why automated regression testing is a best practice. I guess Dropbox don't test their authentication.

Re:Regression testing (1)

cgeys (2240696) | more than 3 years ago | (#36510860)

More than that, wasn't dropbox supposed to encrypt all the content based on password? Yeah, it was shown they had a way to roll it back before, but aren't they doing it at all now?

Re:Regression testing (5, Informative)

Richard_at_work (517087) | more than 3 years ago | (#36510902)

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:Regression testing (2)

Lieutenant_Dan (583843) | more than 3 years ago | (#36511046)

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 as well close shop now.

Re:Regression testing (5, Informative)

Richard_at_work (517087) | more than 3 years ago | (#36511086)

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:Regression testing (1)

Lieutenant_Dan (583843) | more than 3 years ago | (#36511174)

Damn; you're right [informationweek.com] .

I get it that it would take the a whole lot processing power to deal with the slew of private keys, but beyond that, encryption in this case looks gimmicky for the user. Only good if someone hacks in the FS remotely, steals a backup tape, or finds a discarded drive from their SAN.

Yeah, this is really nothing special. Maybe we should build our own?

Re:Regression testing (1)

abhi_beckert (785219) | more than 3 years ago | (#36511296)

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:Regression testing (0)

Anonymous Coward | more than 3 years ago | (#36511988)

Clearly whoever's in charge of their security is not doing a good job.

So go do it better.

Put your money where your mouth is.

Re:Regression testing (2)

h4rr4r (612664) | more than 3 years ago | (#36511654)

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:Regression testing (1)

PJ6 (1151747) | more than 3 years ago | (#36511448)

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:Regression testing (1)

Cqfd (2291336) | more than 3 years ago | (#36511494)

Actually this is no proof. Each file could be hashed (to check for dedup before upload), encrypted with a file key (master key), and that file key wrapped with the private keys of users holding that file. So you only need to store the file encrypted by the file key, the hash, and the encrypted file key for each user with access to the file. Well this is how good file encryption works (like in EFS). So multiple users can each have access to a single file, with no key sharing, and no access for other users.

Re:Regression testing (1)

h4rr4r (612664) | more than 3 years ago | (#36511720)

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:Regression testing (2)

Eivind (15695) | more than 3 years ago | (#36511628)

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 stopping you from storing the session-key encrypted with *both* (or more than 2) private-keys.

This is the same thing GPG and friends do if you specify 2 or more recipients for the same message. They encrypt the actual message only once, with a one-time random key. Then they encrypt that *key* once for each recipient. This saves space 'cos the key is typically much smaller than the message.

You'd need the hashes unencrypted though, to be able to tell that two people have the same files -- even if you don't know what's in those files. And this does, offcourse, leak *some* of their privacy. (one could, for example answer the question: does person X have file Y, yes or no ?)

Re:Regression testing (1)

Chris Mattern (191822) | more than 3 years ago | (#36511206)

they use one single encryption key for all data stored.

Well, gee, that makes me feel good about their security...

Re:Regression testing (4, Insightful)

gstoddart (321705) | more than 3 years ago | (#36511422)

Well, gee, that makes me feel good about their security...

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:Regression testing (1)

flimflammer (956759) | more than 3 years ago | (#36511516)

the fact that it's only *slightly* more secure than a public folder on a shared network

Holy exaggerations, batman?

Re:Regression testing (4, Funny)

buchner.johannes (1139593) | more than 3 years ago | (#36510890)

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>

Re:Regression testing (1)

phatcabbage (986219) | more than 3 years ago | (#36510968)

<sarcasm>It obviously works well enough to keep your XML tags matched.</sarcasm>

Re:Regression testing (5, Funny)

Nikker (749551) | more than 3 years ago | (#36511016)

This is Slashdot, the start tag was posted in 1999.

Re:Regression testing (1, Funny)

jamesh (87723) | more than 3 years ago | (#36511048)

snap!

Re:Regression testing (1)

Centurix (249778) | more than 3 years ago | (#36511190)

You mean that someone has finally closed the sarcasm tag on Slashdot?

No wait, must be nested a few deep.

The Most Interesting Developer In The World (5, Funny)

Kozz (7764) | more than 3 years ago | (#36511366)

I don't test my code. But when I do, I do it in Production,

Re:The Most Interesting Developer In The World (0)

Anonymous Coward | more than 3 years ago | (#36511952)

You work for Microsoft don't you?

Re:The Most Interesting Developer In The World (1)

equex (747231) | more than 3 years ago | (#36512442)

Sounds like every company I ever worked for.

How about testing? (2)

mcvos (645701) | more than 3 years ago | (#36510848)

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:How about testing? (0)

Anonymous Coward | more than 3 years ago | (#36510872)

Bah! Screw testing, we need $SHINY_NEW_SERVER_FEATURE in production immediately!

Re:How about testing? (1)

GIL_Dude (850471) | more than 3 years ago | (#36510918)

Most likely their automated testing always used the correct password so they didn't see the problem. If their testing included using a few incorrect passwords the problem would have instantly shown itself. Probably just a failure in designing the proper test inputs.

Re:How about testing? (1)

mcvos (645701) | more than 3 years ago | (#36511224)

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:How about testing? (2)

Chris Mattern (191822) | more than 3 years ago | (#36511240)

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 (1)

Rie Beam (632299) | more than 3 years ago | (#36510850)

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:Password Strength (1)

maxume (22995) | more than 3 years ago | (#36510934)

Front door?

This is more like don't leave your valuables in a paper bag on a shelf at the grocery store.

Re:Password Strength (1)

ByOhTek (1181381) | more than 3 years ago | (#36511020)

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:Password Strength (1)

mcvos (645701) | more than 3 years ago | (#36511264)

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:Password Strength (0)

Anonymous Coward | more than 3 years ago | (#36511460)

It still is good to store your keepass database. Just dont store your key file there as well. My keepass database is actually stored both there and publicly available over http on a different site. I really dont care about the database itself, I care about the keyfile and password needed to decrypt the file.

Re:Password Strength (1)

egamma (572162) | more than 3 years ago | (#36511464)

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:Password Strength (1)

RobbieThe1st (1977364) | more than 3 years ago | (#36511480)

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:Password Strength (1)

h4rr4r (612664) | more than 3 years ago | (#36511672)

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:Password Strength (1)

mlts (1038732) | more than 3 years ago | (#36512606)

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 physically tamper resistant container. Of course, if the computer I'm on is compromised, I'm hosed. However, brute forcing the data is just not going to happen. Attacks against the container will result in it destroying the contents after 3-10 tries.

This also is no protection against rubber hose cryptography, but one needs to consider their threat level -- it is far more likely for someone to have a remote site compromised with data on it than being kidnapped just for a Word document with a term paper on it. If their threat level means that someone is willing to go and grab them, it takes a completely different cryptographic implementation.

1st (-1)

Anonymous Coward | more than 3 years ago | (#36510852)

1st

Fire the programmers please (2, Insightful)

james_van (2241758) | more than 3 years ago | (#36510856)

Seriously, someone needs to have their head roll. Proper authentication is a.) the first thing I learned when doing web programming b.) reasonably simple to put in place c.) so damned important that even for a small website with nothing particularly sensitive, anyone who drops the ball on it should shown the door with swiftness. I really like Dropbox, but they've had some drama lately and I think it's time to look elsewhere

Re:Fire the programmers please (2)

Lieutenant_Dan (583843) | more than 3 years ago | (#36510936)

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:Fire the programmers please (1)

Anonymous Coward | more than 3 years ago | (#36510950)

So you never make simple stupid mistakes? If you do, should you be fired immediately for them?

I was going to make a nice, respectful comment but in the end the truth must me said: You're an idiot.

Re:Fire the programmers please (0)

Anonymous Coward | more than 3 years ago | (#36511092)

you're the idiot. if you make a "simple mistake" that could easily end your company you should probably be let go.

Re:Fire the programmers please (1)

Abstrackt (609015) | more than 3 years ago | (#36511120)

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:Fire the programmers please (1)

228e2 (934443) | more than 3 years ago | (#36511280)

Doubly agree for a different reason. $.

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:Fire the programmers please (1)

SumterLiving (994634) | more than 3 years ago | (#36511824)

Dropbox will suffer in terms of reputation, customer retention, and future customers if they fire the programmer or not. Coming from a guy who just got laid off in favor of keeping a guy who took well over 1 hour to troubleshoot a broken "left mouse button", firing might result in better company profits in hourly wage and vacation time. But gotta admit, I buttted heads with my "nontechnical" boss who told me how to fix each and every problem that came up on our systems. I finally gave up and did things "his way" without pointing out the future implications his "fix" would result in. Now they have "Mr Left Mouse Button" to find and fix the problems. Making an honest mistake shouldn't be the end of the world but rather a way not to conduct business in the future. My mistake was not quitting 5 years earlier. But if did that I would have missed my boss's "bad juju" explanation to upper management as to why our some of our systems weren't working very well. That was priceless for the 1st few weeks but got rather embarrassing when it became "the standard" up channeled answer in my last 3 years.

Re:Fire the programmers please (0)

Anonymous Coward | more than 3 years ago | (#36511298)

> Personally, I agree that something of this magnitude is sackworthy.

And then the precedent will be set that mistakes are final. No-one will suggest any changes that might go awry, innovation will cease and the company will atrophy.

Eventually everyone will be "let-go".

Make the responsible programmer clear up each and every problem which his mistake caused, but don't sack him.

Re:Fire the programmers please (1)

Abstrackt (609015) | more than 3 years ago | (#36512646)

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?

Re:Fire the programmers please (1)

james_van (2241758) | more than 3 years ago | (#36511134)

You have a valid point in that people should not be fired for most simple, stupid mistakes. God knows I've made plenty. I'm just saying that dropping the ball on authentication is a pretty big deal. Especially for something like Dropbox. From personal experience where I work, there are lots of simple stupid mistakes that would get me called into an office and reprimanded, theres plenty that would be overlooked, but there are a few that are grounds for immediate release from employment. Problems with authentication is one of them. I would agree with Lt Dan, it probably was a holdover from some testing and so the blame lies on mulitple people/groups. In that case, firing whole teams isn't a reasonable answer, but a solid reprimand across the board to make sure that everyone knows this sort of thing can't happen again would be in order. Also, I am in idiot. I have a bad habit of making strongly worded statements initially, that, had I taken a little more time to think them through would have come out as a tad more reasonable. It drives my wife nuts.

Re:Fire the programmers please (1)

Anonymous Coward | more than 3 years ago | (#36511950)

(original AC) I myself am a small business owner and I'm not about to fire a talented programmer because he made a small error that was quickly fixed that only temporarily affected the reputation of my company. People will forget about this in two weeks. If my programmer was stealing from me or caused an error that rm -rf'd our code server and all backups, I would fire him/her with a smile on my face. Otherwise you must acknowledge that we're all human and there has to be some leeway when errors are made in good faith.

Re:Fire the programmers please (1)

jamesh (87723) | more than 3 years ago | (#36511062)

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:Fire the programmers please (1)

chemicaldave (1776600) | more than 3 years ago | (#36511064)

If programmers lost their heads whenever another programmer was upset with their work, there would be no programmers left.

...except me of course.

Re:Fire the programmers please (1)

Abstrackt (609015) | more than 3 years ago | (#36512222)

"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization."

Re:Fire the programmers please (1)

Anonymus (2267354) | more than 3 years ago | (#36511274)

The person who's head should roll is the manager in charge of establishing good practices. No single person should be involved in a mistake of this magnitude. If I were at the head of this company, I wouldn't fire the programmer who made a simple mistake, I would fire whoever above him didn't prevent mistakes like that from happening in the first place.

Let me summarize every comment that will appear: (1)

Shikaku (1129753) | more than 3 years ago | (#36510858)

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:Let me summarize every comment that will appear (1)

Anonymous Coward | more than 3 years ago | (#36510992)

5. Let me summarise what comments will be posted.

Re:Let me summarize every comment that will appear (0, Offtopic)

Anonymous Coward | more than 3 years ago | (#36511032)

6. Corrections and additions to other peoples comments

Re:Let me summarize every comment that will appear (1)

WhitetailKitten (866108) | more than 3 years ago | (#36511028)

I substitute a different one that, if one were to be uncharitable in a particular direction, could appear on your list:

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 production. Something like Carbonite or Mobile Me (I know, put the pitchforks down) depends on its paying customers to stay and keep paying. Freemium depends on enticing its free customers into becoming paying customers. These are different priorities.

I do have to admit that I have a LastPass account, but I do pay for the premium subscription, and I only signed up after doing a bunch of research; I'm confident that they've done things right as much as possible. With LastPass, I'm the weakest point in the chain (social engineering, weak master passwords, and physical access to local machines are the easy targets over trying to brute force the encrypted blob LP's servers receive when my vault syncs).

Disclaimer: I have no affiliation with Carbonite, Apple, or LastPass, okay?

Re:Let me summarize every comment that will appear (2)

h4rr4r (612664) | more than 3 years ago | (#36511794)

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?

And thats why (1)

dimethylxanthine (946092) | more than 3 years ago | (#36510880)

I have a box sitting in a decomissioned nuclear bunker running OpenAFS and securely wrapped Samba.

Fixed in five minutes? (1)

MichaelSmith (789609) | more than 3 years ago | (#36510892)

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:Fixed in five minutes? (1)

Dodgy G33za (1669772) | more than 3 years ago | (#36511108)

Unless they discovered the problem and followed a backout script.

Re:Fixed in five minutes? (1)

MichaelSmith (789609) | more than 3 years ago | (#36511148)

Unless its the proverbial

echo ENABLE_AUTH=YES >> /etc/rc.conf

...then I doubt it.

Re:Fixed in five minutes? (1)

Kjella (173770) | more than 3 years ago | (#36511154)

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:Fixed in five minutes? (1)

RobbieThe1st (1977364) | more than 3 years ago | (#36511596)

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.

What's more alarming... (0)

Anonymous Coward | more than 3 years ago | (#36510904)

Doesn't this mean that none of the data on their servers is truly encrypted in any way? If the programmer could put $userAuthenticated=TRUE into the code and suddenly have access to any account's data, then how, exactly, is the encryption occurring period?

Re:What's more alarming... (1)

camperdave (969942) | more than 3 years ago | (#36512042)

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=DECRYPT(PASSWORD) you have IF VALIDATED(USER) THEN DATA=DECRYPT(KEYLOOKUP(USER))

Lack of organizational maturity (1)

Lieutenant_Dan (583843) | more than 3 years ago | (#36510910)

Easy to criticize from the other side, but obviously change management and solid SLDC practices are not in place. I know that they're pretty much a start-up and their end-goal is a juicy IPO. They need to consider that they're a target for all the security hacks and other "cloud" providers.

All they need is to get one sensible person to review and validate the releases. They can keep their internal cowboy style, just as it hits or affects prod, then someone needs to sign it with blood.

I'm sure they will learn from this. Their rep has suffered major damage (again).

Relax, it was only 4 hours. (5, Funny)

Combatso (1793216) | more than 3 years ago | (#36510914)

Relax honey, I only left our baby alone in the bathtub for four hours.
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:Relax, it was only 4 hours. (2)

SJHillman (1966756) | more than 3 years ago | (#36511000)

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. (1)

Anonymous Coward | more than 3 years ago | (#36511338)

Or more realistically:

Relax homeowner, the door has been closed but unlocked for the last four hours, but fortunately there is no evidence of any unauthorized access.

Re:Relax, it was only 4 hours. (5, Interesting)

xtracto (837672) | more than 3 years ago | (#36511600)

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 (3, Insightful)

Wuhao (471511) | more than 3 years ago | (#36510928)

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.

What Else Did They Do? (1)

Rie Beam (632299) | more than 3 years ago | (#36510932)

Was there any sort of check down after-the-fact to ensure that improper logins were terminated / any changes rolled back?

Re:What Else Did They Do? (1)

Richard_at_work (517087) | more than 3 years ago | (#36510984)

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 here because Dropbox themselves would not know which activity was legitimate and which was not.

Re:What Else Did They Do? (1)

h4rr4r (612664) | more than 3 years ago | (#36511844)

So what magic do they use to rollback the breach of your privacy?

Professional Code: Secure Pre-Flight Testing? (1)

BoRegardless (721219) | more than 3 years ago | (#36510948)

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:Professional Code: Secure Pre-Flight Testing? (1)

varcher (156670) | more than 3 years ago | (#36511282)

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:Professional Code: Secure Pre-Flight Testing? (1)

rjstanford (69735) | more than 3 years ago | (#36511372)

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 expected practices. We know how to get a really good head start on keeping systems secure, but it takes a lot of time, money, and will to succeed.

Drop it! (0)

Anonymous Coward | more than 3 years ago | (#36510976)

I for one is dropping Dropbox.

Honor system (1)

adolf (21054) | more than 3 years ago | (#36511034)

"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! (1)

gman003 (1693318) | more than 3 years ago | (#36511070)

I use DropBox, but I don't trust it to actually be secure. So I use it as a publishing tool and offsite backup for public things. All the stuff I have on there is essentially public - a bunch of images I wanted to share, and a few tarballs of GPL'ed source code to a game I'm writing. I have copies on my local machine, so Dropbox could collapse into a black hole without me losing any data. It's all stuff I want people to see, so the privacy and security of the account aren't of any concern.

Stuff like this have essentially proven that I was correct in not trusting Dropbox. It's a great tool - it's the easiest way to make 50 images publicly-viewable, and it's a good simple way to mirror some big file - but I don't think it's yet secure enough to be as safe as local data storage.

Re:Vindication! (1)

fast turtle (1118037) | more than 3 years ago | (#36511686)

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.

hello webmaster (1)

formation (2241238) | more than 3 years ago | (#36511088)

Check to see if your Company name is available http://bit.ly/m2IHF4 [bit.ly]

Simple release mixup (1)

jamesh (87723) | more than 3 years ago | (#36511090)

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 (1)

GameboyRMH (1153867) | more than 3 years ago | (#36511110)

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 overworked and underpaid), but they have their own skyscraper and everything so I really can't maintain that idea.

Dropbox - because vanilla FTP wasn't bad enough (1)

dbIII (701233) | more than 3 years ago | (#36511130)

How can you fuck up something worse than a system devised back when nobody on the net really cared about security?

PST or PDT? (0)

Anonymous Coward | more than 3 years ago | (#36511146)

I frequently see PST mistakenly being used when PDT is in effect. That is probably what happened here too.

A request to all developers (0)

Anonymous Coward | more than 3 years ago | (#36511150)

If you have created software that has dropbox capability, can you please add other storage providers so that I can switch away from dropbox? Please?

this is not just a problem with them (0)

Anonymous Coward | more than 3 years ago | (#36511182)

I have been involved with the installation of a lot of software over the years. Over the last few years, 3 or 4 maybe, I've seen this type of thing more and more.

It doesn't seem like anyone properly tests anything anymore. They just push it out the door and hope that no one complains. I wish these companies would stop buying everyone $5000 macs to code on and put that money to better use hiring actual software testers.

YOU CANNOT ACCURATELY PROOF YOUR OWN WRITING!

this goes for coding to.

Oh noes! (1)

One Monkey (1364919) | more than 3 years ago | (#36511270)

All the worthless and mostly meaningless crap I had in my dropbox was available to the world for four hours. Poor world. I'm sorry.

Seriously. It's a cloud based file-syncing service any "security" you imagine files have in there inherently is entirely fictional.

the sig... read the sig ! (0)

obarthelemy (160321) | more than 3 years ago | (#36511364)

slashdot should allow modding sigs up !

Dropbox + TrueCrypt (0)

Anonymous Coward | more than 3 years ago | (#36511436)

Well, I guess it's good that over the weekend I wrapped everything I had on Dropbox in an AES+Twofish TrueCrypt container.

YOU CAUSED SO MUCH HAVOC (0)

Anonymous Coward | more than 3 years ago | (#36511468)

You wreaked havoc for me, Dropbox.
This is a major booboo.

MY GMAIL HAS BEEN SPEWING SPAMS TO ALL CONTACTS YESTERDAY until this morning.

I almost got into a fight when I traced the IP address and found the owner.
I sill haven't found the hacker, but this all happened thanks to you!

Trust the Cloud? (1)

seven of five (578993) | more than 3 years ago | (#36511502)

You can trust the cloud when the servers are overseen by people who never make mistakes, when the hardware runs perfectly all the time, and when all other human beings agree to not screw with the system.

Re:Trust the Cloud? (1)

Anonymous Coward | more than 3 years ago | (#36512228)

You can trust the cloud when the servers are overseen by people who never make mistakes, when the hardware runs perfectly all the time, and when all other human beings agree to not screw with the system.

Which is exactly the same for trusting a server run locally?

"To the cloud!" (0)

Anonymous Coward | more than 3 years ago | (#36511984)

Wee! *marketing manager jumps off building wearing a cape*

slipping relevancy (1)

tachin1 (763958) | more than 3 years ago | (#36512264)

On a semi related note, I read this on boingboing yesterday about 24 hours ago, slashdot seems to be slipping.

Encrypted? I don't think so... (0)

Anonymous Coward | more than 3 years ago | (#36512282)

Well, I guess this definitely proves that all of their talk about encryption is bunk. Obviously if you could log in and access files using the wrong password, whatever "encryption" they're using to store the files on their end doesn't actually encrypt anything.

No longer an issue. (0)

Anonymous Coward | more than 3 years ago | (#36512552)

Remember when people learned that their "encryption" of data wasn't really encryption but merely a series of permission filters giving people either "user" access or "admin" access to your files?

Who needs to worry about encryption or permissions to your files when there's absolutely no form of authentication at all?!

Very strange way to solve their encryption issues if you ask me.... but I guess it's no longer an issue.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?