Forgot your password?
typodupeerror
Cloud Bug Data Storage Security Hardware

Dropbox Password Goof Let Any Password Work For 4 Hours 185

Posted by timothy
from the you'll-find-we're-very-open-minded. dept.
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."
This discussion has been archived. No new comments can be posted.

Dropbox Password Goof Let Any Password Work For 4 Hours

Comments Filter:
  • Regression testing (Score:5, Informative)

    by Bogtha (906264) on Tuesday June 21, 2011 @08:04AM (#36510846)
    This is why automated regression testing is a best practice. I guess Dropbox don't test their authentication.
    • by buchner.johannes (1139593) on Tuesday June 21, 2011 @08:09AM (#36510890) Homepage Journal

      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>

    • My best guess is the feds took the opportunity to check dropbox.

  • by mcvos (645701) on Tuesday June 21, 2011 @08:04AM (#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.

    • by GIL_Dude (850471)
      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.
      • by mcvos (645701)

        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.

      • 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 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...

    • by ByOhTek (1181381)

      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.

      • by mcvos (645701)

        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.

        • by egamma (572162)

          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.

        • 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.

          • by gr8dude (832945)

            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.

            • by heypete (60671)

              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.

        • by makomk (752139)

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

      • by h4rr4r (612664)

        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.

        • by mlts (1038732) *

          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

  • 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
    • 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.

    • by jamesh (87723)

      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?

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

      ...except me of course.

      • by Abstrackt (609015)

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

    • by mlts (1038732) *

      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

    • by rubycodez (864176) on Tuesday June 21, 2011 @11:02AM (#36513086)
      bugs will happen, all the time. The problem here is that there are processes missing, management has failed. Your ideas of software development need to change, it is not a one-man-band.
  • 1. Open source or GTFO
    2. Cloud is dangerous; this is why cloud fails
    3. I like dropbox
    4. Stop with the dropbox spam.

    • 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
      • by h4rr4r (612664)

        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?

        • by mlts (1038732) *

          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

          • by h4rr4r (612664)

            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.

            • by mlts (1038732) *

              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

              • by h4rr4r (612664)

                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.

  • 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.

    • by Kjella (173770)

      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.

      • 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.

  • by Combatso (1793216) on Tuesday June 21, 2011 @08:11AM (#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
    • 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.

  • by Wuhao (471511) on Tuesday June 21, 2011 @08:14AM (#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.

    • by Cato (8296)

      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.

      • by heypete (60671)

        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.

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

    • 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

  • 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.

    • by varcher (156670)

      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.

    • by rjstanford (69735)

      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

  • "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.]

  • 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
    • 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.

  • 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.

  • 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

  • How can you fuck up something worse than a system devised back when nobody on the net really cared about security?
    • 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?

  • 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.
  • A lot of people are saying you shouldn't keep anything sensitive in the cloud but having your personal data exposed isn't the only problem here. Dropbox automatically synchronizes to your PC so during this period anyone could have pushed any file out to your PC without your knowledge --maybe substitute an EXE with a virus, or replace your family photos with child porn.
  • I wondered how "Mad Dog 20/20" got on our grocery list.

God made machine language; all the rest is the work of man.

Working...