Dropbox Password Goof Let Any Password Work For 4 Hours

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

Comments

Regression testing

[Bogtha]

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

Re:Regression testing

[cgeys]

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

[buchner.johannes]

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

[Richard_at_work]

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

[phatcabbage]

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

Re:Regression testing

[Nikker]

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

Re:Regression testing

[Lieutenant_Dan]

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

[jamesh]

snap!

Re:Regression testing

[Richard_at_work]

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

[Lieutenant_Dan]

Damn; you're right.

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

[Centurix]

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

No wait, must be nested a few deep.

Re:Regression testing

[Chris Mattern]

they use one single encryption key for all data stored.

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

Re:Regression testing

[abhi_beckert]

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.

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

[gstoddart]

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

[PJ6]

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

[Cqfd]

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

[flimflammer]

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

Holy exaggerations, batman?

Re:Regression testing

[Eivind]

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

[h4rr4r]

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

[h4rr4r]

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

[Anonymous Coward]

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

[rubycodez]

they should have used tools like IBM's Rational Unified Process, that lets every idiot in the building interfere with the development process, and also barfs out impressive diagrams every time that happens

Re:Regression testing

[Goaway]

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:Regression testing

[Goaway]

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:Regression testing

[dbIII]

Yes, but do you think these clowns that couldn't even get an FTP replacement to be as secure as FTP went to that much trouble? You can't even give people temporary access by doing password changes with this mess but to make things worse it gives you the illusion that it is doing so.

Re:Regression testing

[gstoddart]

Holy exaggerations, batman?

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 is in any way robust?

As soon as your data is in someone else's hands, you more or less have to assume that without your own level of encryption, the files are vulnerable. Which, pretty much sums up Dropbox.

Don't get me wrong, I have used it for quite a while now -- I'm just very selective about what I use it for. Work stuff that I wouldn't be able to put on a US based server due to data protection laws, for example, I wouldn't put it on there. I explicitly don't assign that level of trust to them.

Re:Regression testing

[Anonymous Coward]

SHA256 is also a hash function, not an encryption function. The purpose of a hash is to be one-way... which would make decryption impossible except by attack. So using something like SHA256 would be better for the hash (much better than MD5)... then use something like AES for encryption.

Re:Regression testing

[h4rr4r]

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:Regression testing

[thehodapp]

Welcome to the club. We have many options available. Extremely cheap, high capacity, super-crash-splash-resistant flash-drives (key-ring included!), portable hard-drives, SD-cards (32 Gigs for phones these days?!). All options are always locally available, very reliable, and highly portable. Oh, did we mention quite safe from public consumption?

Re:Regression testing

[Amouth]

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:Regression testing

[Amouth]

*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:Regression testing

[hawkinspeter]

Why not? Surely block level dedupe is the only way to dedupe if they can't access the unencrypted files.

Re:Regression testing

[StarsAreAlsoFire]

I don't know about your data, but my private data is certainly encrypted using its own keyfile. It is, after all, *MY* responsibility to secure my own data.

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:Regression testing

[Eivind]

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 encrypt(new_randomkey, public_key_of_1) and encrypt(new_randomkey, public_key_of_2).

This means user 2 must *upload* the file, despite the file already being present in the cloud, which is a drawback as it amounts to wasted bandwith. But the -storage- advantages of storing the file only once, rather than twice, can still be realised.

Re:Regression testing

[Goaway]

Yes, but I think a large part of why they do this is because of the bandwidth savings.

How about testing?

[mcvos]

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?

[Anonymous Coward]

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

Re:How about testing?

[GIL_Dude]

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?

[mcvos]

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?

[Chris Mattern]

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

[Rie Beam]

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

[maxume]

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

[ByOhTek]

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

[mcvos]

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

[Anonymous Coward]

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

[egamma]

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

[RobbieThe1st]

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

[h4rr4r]

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

[mlts]

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.

Re:Password Strength

[gr8dude]

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:Password Strength

[heypete]

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:Password Strength

[makomk]

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:Password Strength

[Anonymous Coward]

Indeed, and your bitcoin wallet and other sensitive information should be protected in a secure WinZip or TrueCrypt file with a very strong password.

Fire the programmers please

[james_van]

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

[Lieutenant_Dan]

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

[Anonymous Coward]

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

[jamesh]

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

[chemicaldave]

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

[Anonymous Coward]

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

[Abstrackt]

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

[james_van]

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

[Anonymus]

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.

Re:Fire the programmers please

[228e2]

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

[Anonymous Coward]

> 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

[SumterLiving]

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

[Anonymous Coward]

(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

[Abstrackt]

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

Re:Fire the programmers please

[Abstrackt]

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

[EvilSpudBoy]

Well sure, but civilization 2.0 will be awesome and existing users can upgrade at half price!

Re:Fire the programmers please

[mlts]

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

Re:Fire the programmers please

[tnk1]

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 possibly make that mistake ever again. Of course, you'd be wrong. Anyone can make a huge mistake if given the right opportunity to do so.

It all depends on the circumstances. If the mistake is a failure of process where a small mistake can be magnified into a big mistake through the way the system works, firing the person who touched off the disaster is probably not the right thing to do. Everyone is going to make errors, even when it is relatively simple to not make that error.

On the other hand, if an employee has inherent character flaws that make him a danger no matter how good your process is, he needs to be fired immediately, preferably before he screws you, not afterward.

In any event, if your process sucks, firing the guy who touched off the issue doesn't fix the problem. All that happens is the process is primed for the next person to make an error and screw you. It may feel right to hold someone responsible, but that's not always the answer.

Re:Fire the programmers please

[Anonymous Coward]

Another retard that knows nothing of development speaks.

Re:Fire the programmers please

[228e2]

Don't get me wrong, I'm not saying that is the way it SHOULD be done, just that in this day and age, I would be very surprised if it isn't done.

Let me summarize every comment that will appear:

[Shikaku]

1. Open source or GTFO
2. Cloud is dangerous; this is why cloud fails
3. I like dropbox
4. Stop with the dropbox spam.

And thats why

[dimethylxanthine]

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

Fixed in five minutes?

[MichaelSmith]

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?

[Dodgy G33za]

Unless they discovered the problem and followed a backout script.

Re:Fixed in five minutes?

[MichaelSmith]

Unless its the proverbial

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

...then I doubt it.

Re:Fixed in five minutes?

[Kjella]

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?

[RobbieThe1st]

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

[Anonymous Coward]

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

[camperdave]

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

Re:What's more alarming...

[DaVince21]

One master key for all Dropbox data (except the public/image data of course).

Lack of organizational maturity

[Lieutenant_Dan]

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.

[Combatso]

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.

[SJHillman]

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.

[Anonymous Coward]

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.

[xtracto]

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

[Wuhao]

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:Dropbox's followup is no good

[Cato]

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:Dropbox's followup is no good

[heypete]

You might be interested in CrashPlan. 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.

Re:Dropbox's followup is no good

[Anonymous Coward]

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.

Box.net?

Re:Dropbox's followup is no good

[Anonymous Coward]

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.

[Citation Needed]

You mean this email?

Hi First name,

We are writing because there was some activity in your Dropbox account that we'd like you to review. On June 19, 2011, there was a brief bug with our authentication system that could have allowed unauthorized access to accounts. You can read more about it at our blog post.

Based on a careful review of our records, we noticed that during the time the bug was in effect you:

        Linked the desktop application to your Dropbox

As a precautionary measure, we disabled any apps.

While it's unlikely, we'd like to be cautious and make sure this was you because if the activity was unauthorized, the information in your account could have been improperly accessed. Please review recent activity in your account, which you can access at http://www.dropbox.com/events, and let us know if you find anything suspicious.

We are very sorry and this should never have happened. We are scrutinizing our controls and will be implementing additional safeguards to prevent this from happening again. If you're unable to access your account or have any other questions or concerns, please contact us at support@dropbox.com.

- The Dropbox Team

Re:Dropbox's followup is no good

[matzahboy]

Not true. I got an email at 5:30am this morning informing me of the security breach.

Re:Dropbox's followup is no good

[mattcsn]

I had similar problems with Spideroak. I wanted to like it, since it seemed a good way to backup and sync files across multiple machines at a reasonable price, but the client software is a huge resource hog on both Windows and Linux.

What Else Did They Do?

[Rie Beam]

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?

[Richard_at_work]

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?

[h4rr4r]

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

Re:What Else Did They Do?

[Anonymous Coward]

The breach? Duct tape of course!

Re:What Else Did They Do?

[prikkebeen]

So, for how many illegitimate and/or not allowed users do you want me to de-download your private data? I have to contact them individually you see.

Professional Code: Secure Pre-Flight Testing?

[BoRegardless]

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.

Drop it!

[Anonymous Coward]

I for one is dropping Dropbox.

Re:Let me summarize every comment that will appear

[Anonymous Coward]

5. Let me summarise what comments will be posted.

Re:Let me summarize every comment that will appear

[WhitetailKitten]

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

[Anonymous Coward]

6. Corrections and additions to other peoples comments

Honor system

[adolf]

"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!

[gman003]

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!

[fast turtle]

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

[jamesh]

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.

Re:Simple release mixup

[Anonymous Coward]

I see I wasn't the only one who had that thought :-)

The image in my head of Dropbox

[GameboyRMH]

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.

Re:The image in my head of Dropbox

[Anonymous Coward]

In my experience it's rarely that programmers are incompetent but that they're forced to code stupid designs and rush security. I cringe whenever I see other programmers on the outside readily blame programmers for being incompetent when they have their boss telling them to do X or find a new job.

Dropbox - because vanilla FTP wasn't bad enough

[dbIII]

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

Re:Dropbox - because vanilla FTP wasn't bad enough

[93 Escort Wagon]

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?

PST or PDT?

[Anonymous Coward]

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

A request to all developers

[Anonymous Coward]

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

[Anonymous Coward]

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!

[One Monkey]

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.

Re:Professional Code: Secure Pre-Flight Testing?

[varcher]

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.

the sig... read the sig !

[obarthelemy]

slashdot should allow modding sigs up !

The Most Interesting Developer In The World

[Kozz]

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

Re:The Most Interesting Developer In The World

[Anonymous Coward]

You work for Microsoft don't you?

Re:The Most Interesting Developer In The World

[equex]

Sounds like every company I ever worked for.

Re:The Most Interesting Developer In The World

[Anonymous Coward]

Production makes the most accurate test environment.

Re:The Most Interesting Developer In The World

[Anonymous Coward]

Ouch. That's hitting too close home.

Re:The Most Interesting Developer In The World

[Anonymous Coward]

That would be a good T-shirt

Re:The Most Interesting Developer In The World

[Anonymous Coward]

"Regression testing"? What's that? If it compiles, it is good; if it boots up, it is perfect.

-- Linus Torvalds

Re:The Most Interesting Developer In The World

[radish]

Saw this on one of the more amusing github comment threads of recent times.

Re:Professional Code: Secure Pre-Flight Testing?

[rjstanford]

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.

Dropbox + TrueCrypt

[Anonymous Coward]

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

[Anonymous Coward]

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!

Re:YOU CAUSED SO MUCH HAVOC

[equex]

The consequsnces will never be the saem !!1 Oh and also free stuff must work 100% of the time! WHAT DO YOU MEAN MY FREE SERVICES IS NOT SECURE!!!??

Trust the Cloud?

[seven of five]

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?

[Anonymous Coward]

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?

Re:Let me summarize every comment that will appear

[h4rr4r]

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?

"To the cloud!"

[Anonymous Coward]

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

slipping relevancy

[tachin1]

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

[Anonymous Coward]

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.

[Anonymous Coward]

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.

Password database

[nekohayo]

I never used dropbox for anything more than a handful spreadsheets I had to work with in school, because I never entrusted the "cloud" with my sensitive data. This is why iFolder (and now SparkleShare) are so promising, and why I keep using Unison in the meantime. The big question I have to ask today is: were the dropbox user account passwords accessible, or was it "just" the files? I need to know if I have to change the dozens of websites that use that particular password *again* (remember the Gawker password dump?).

too many companies do this

[vonshavingcream]

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.

Data exposure isn't the only consequence.

[EvilSpudBoy]

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.

Re:Let me summarize every comment that will appear

[mlts]

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 fund to deal with the destruction of all data stored with them should they go bankrupt or cease operations. The destruction would be done by an independent party who would show certificates of the destruction, and have insurance so if data wasn't really destroyed, people can file claims.

This way, either the data will be stored as per a SLA, or it will be destroyed.

wrong kind of thinking

[rubycodez]

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.

Re:Let me summarize every comment that will appear

[c0nner]

You forgot the subcategory of

3. I like dropbox
    3.a Use my referal code because I am too cheep to pay for real service.

Re:Professional Code: Secure Pre-Flight Testing?

[Anonymous Coward]

...you have teams of very smart people dedicated to breaking it. Which isn't what happened in this case, ...

Are you implying thet DropBox developers aren't smart? ;-)

Re:Let me summarize every comment that will appear

[h4rr4r]

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.

use truecrypt

[Anonymous Coward]

Use dropbox like I do, in a secure fashion. I have a truecrypt container that I mount from inside dropbox, that way my data is safe to their and NSA's spying!
 

Here is a Laugh - From Drop Box's Web Site

[Anonymous Coward]

https://www.dropbox.com/help/27

=== start ===
How secure is Dropbox?

Your files are actually safer while stored in your Dropbox than on your computer in some cases. We use the same secure methods as banks and the military.

Dropbox takes the security of your files and of our software very seriously. We use the best tools and engineering practices available to build our software, and we have smart people making sure that Dropbox remains secure. Your files are backed-up, stored securely, and password-protected.

Other Dropbox users can't see your private files in Dropbox unless you deliberately invite them or put them in your Public folder. Everything in your Public folder is, by definition, accessible to anyone.
Dropbox employees are prohibited from viewing the content of files you store in your Dropbox account, and are only permitted to view file metadata (e.g., file names and locations). Like most online services, we have a small number of employees who must be able to access user data for the reasons stated in our privacy policy (e.g., when legally required to do so). But that’s the rare exception, not the rule. We have strict policy and technical access controls that prohibit employee access except in these rare circumstances. In addition, we employ a number of physical and electronic security measures to protect user information from unauthorized access.
=== end ===

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Let me summarize every comment that will appear

[mlts]

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 hardware that happened to have some data on it and decided to do what he wanted. Copyright violation? Nope. The data was stored at the permission of the cloud computing provider and client.

Can you sue the cloud provider? Stand in line behind the big boys who already have the auction proceeds going to them.

This is where the government needs to step in and offer guarentees for a certain status, with the responsibilities. Want the "secure cloud provider" certification? Put some money in escrow so data can be destroyed under the eye of a Federal agency or a contractor. Combine this with a true SLA that is enforced not just with a piece of paper, but underwritten by an insurance firm, similar to how people are surety bonded.

Then, cloud computing might be a decently secure alternative to the age old tape rotations and the Iron Mountain van visiting on its usual schedule.

The Cloud

[Anonymous Coward]

You rely on someone else....for security? Has no one told you that if you're not in charge of your own security, then you essentially have none???

Re:Let me summarize every comment that will appear

[h4rr4r]

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.

Goof? WTF?

[pyneiii]

Goof? Really? If this were Sony, we'd be calling for their heads on a platter because our private data was potentially breached! A goof is when I forget the parking brake on my car and it rolls into another car in the parking lot. A goof is when you take a test but forget to check that backside for questions. Ridiculous lack of QA thereby putting information (whether you should trust the cloud or not) at risk is unacceptable, especially given the 4 hours it took to recover. Note: I hate Sony as much as the rest of /., but like equality.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Ah, that explains it

[93 Escort Wagon]

I wondered how "Mad Dog 20/20" got on our grocery list.

DropBox Jester

[Anonymous Coward]

A look at the CTO's LinkedIn page shows him with a jester hat.

http://www.linkedin.com/in/arashferdowsi

How fitting.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Backdoor for feds?

[elucido]

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

Best alternative: SugarSync

[Anonymous Coward]

Good article – here is another cloud storage solution that is fully encrypted:
With SugarSync, you get 5GB of cloud storage space with the FREE version, but now there is no restriction to the number of computers you can sync/backup (up from 2).
It gives you the ability to upload and sync any folder on your computer.
It is the only service that offers such a broad device and OS support with apps for BlackBerry, Android, iPhone/iPad, Symbian, not to mention your computer!
You can also stream MP3 music files to your smartphone or computer.

Also if you use the below referral code you get a bonus 500MB extra on top of your Free 5GB!

https://www.sugarsync.com/referral?rf=tbtp0asbw9pt

Hope it helps someone.

I'll tell you this...

[Stone2065]

...at least when this happened, I got an email within 24 hours... not DAYS LATER like some other **coughSONYcough** company finally got around to sending...

Well this is a relief!

[oarion7]

Suddenly I no longer feel like an overly philosophical and paranoid computer geek for refusing to put anything remotely important in my Dropbox account. I was really begining to feel down about myself, that I was overly protective of my privacy and too skeptical of Dropbox. Finally, I can obstain from uploading my files to Dropbox IN PEACE! I'm a new man because of this!

sad day for interwebz freedom fighterz

[Dainsanefh]

sieg heil!

Re:sad day for interwebz freedom fighterz

[Dainsanefh]

sieg heil sieg heil

Re:sad day for interwebz freedom fighterz

[Dainsanefh]

Heil Hitler

Re:sad day for interwebz freedom fighterz

[Dainsanefh]

wooohaaaaaa

Re:sad day for interwebz freedom fighterz

[Dainsanefh]

gv dsgasdgsadg

Re:sad day for interwebz freedom fighterz

[Dainsanefh]

slowdown cowboy

Re:sad day for interwebz freedom fighterz

[Dainsanefh]

xcv xbdf g agsdgsdah

Re:sad day for interwebz freedom fighterz

[Dainsanefh]

how many more?

Re:sad day for interwebz freedom fighterz

[Dainsanefh]

come on there are more?

Re:sad day for interwebz freedom fighterz

[Dainsanefh]

fdshg hdfhsdf

Re:sad day for interwebz freedom fighterz

[Dainsanefh]

vbc xvbndfgr reyher trhfssd

Re:sad day for interwebz freedom fighterz

[Dainsanefh]

Itsuka kitto anata no yume ga kanau made
Mitsumeteitai zutto

Fensu koshi itsudemo kaze ni yureru sebangou
Dare yori mo anata no koe ga hibiiteru
Natsu no hizashi no naka hi ni yaketa yokogao
Genki ni waratteru anata wo mitsumeteta

Dare mo inai gurando hitori anata no
Yume wo kanjiteita no

Ganbare yume ni mukatte hashiritsuzukeru
Anata dake ni eeru wo okuritai itsudemo
Gooru ha tooi keredo kujikenai de
Mada minu hi ni deau made

Anata no yunihoomu yuuhi ni akaku somaru
Ashita mo aeru noni naze ka sabishikute
Muchuu de oikakeru massuguna hitomi ni
Deatta ano hi kara anata ni koi wo shita

Ganbare yume ni mukatte hashiritsuzukeru
Anata dake ni eeru wo okuritai itsudemo
Gooru ha tooi keredo kujikenai de
Mada minu hi ni deau made

Subete ga umaku ikanai tsurai toki demo
Sono mama no anata de ite kawaranai de
Anata ni koishite hajimete mitsukerareta
Yuuki wo ima todokeru kara

Re:sad day for interwebz freedom fighterz

[Dainsanefh]

cxv fte wrtgrea trweyg ehu rtujrtuj

Re:sad day for interwebz freedom fighterz

[Dainsanefh]

98reu t3489utg43j pgyerh p8hyqeryh

Re:sad day for interwebz freedom fighterz

[Dainsanefh]

vcbc htyhrtsh

Re:sad day for interwebz freedom fighterz

[Dainsanefh]

bvnv nvvc rfsg bhehy54eyh

A sneak preview

[Ol Olsoc]

Bow down to the cloud, kiddies. This is your future!

Best alternative: SugarSync

[Anonymous Coward]

Good article – here is another Cloud Storage solution that lets your computer to fully encrypt your files before sending out:
With SugarSync, you get 5GB of cloud storage space with the FREE version, but now there is no restriction to the number of computers you can sync/backup (up from 2).
It gives you the ability to upload and sync any folder on your computer.
It is the only service that offers such a broad device and OS support with apps for BlackBerry, Android, iPhone/iPad, Symbian, not to mention your computer!
You can also stream MP3 music files to your smartphone or computer.

Also if you use the below referral code you get a bonus 500MB extra on top of your Free 5GB!

https://www.sugarsync.com/referral?rf=tbtp0asbw9pt

Hope this helps someone!