I'm pretty curious about the initial break-in on his .mac account. I suspect that either he's misremembering and he has used the password elsewhere (and it was compromised there -- easy to happen over so many years of use), or it wasn't very strong to begin with and it got guessed after a handful of attempts.
There are a handful of takeaways from this:
- Backups, obviously. A lot of people here so far are mentioning online backup services, but those would be just as vulnerable to this kind of attack, since they're accessible online and use an email account for password resets. Online backup services and physical offline backups solve different problems and it's a good idea to use both.
- Since I haven't seen this mentioned anywhere else: I wonder if it's time to consider keeping a "secret" email account that's only used as the password-reset account for all of your services? Something that you never use for communication, never publish anywhere, something with its own entirely separate password.
- Be careful about owning multiple devices from a single vendor that provides remote access and other kinds of control to those devices. Mobile devices are inherently insecure; they shouldn't carry sensitive personal information, ever. There are a lot of really good reasons for going with a single vendor, and remote wipe is a really valuable tool in case of theft, but the downside is ... well, this.
- Use some kind of password storage mechanism. (I prefer something that's not tied in to a publicly-accessible service.) I've made a game out of memorizing horrible passwords, and can recall quite a few without any patterns or mnemonics or the like. Still, I use KeePass every day anyway.
And maybe most of all: I doubt there's a single one of us that has a moral high horse to ride on this. Everybody always has something better to do than set up a new backup system or dick around with something that will only maybe hurt them someday. I'm constantly harping on other people about backups, but only a couple of days ago got my development machine on our network backup system; I'm pretty anal about passwords, but still I'll panic pretty badly if my laptop is ever stolen, because in there, somewhere, is probably a plain text password stored in a file that I've forgotten about, and there'll be a chance that I'll forget to change that particular password if I find myself having to suddenly change every single password for everything I've got access to.
Time Machine (a free utility that ships with OSX, not a military-grade absurdity) would have handled the full restoration of the laptop, which could then restore the wiped iPad and iPhone fully. He'd still have the email hacks to contend with, but at least he'd have his tools back.
It's not his fault that he became a target, and blame for the attack should be firmly limited to the agressor. But the severity of the consequence was clearly amplified by substantial incompetence and / or indifference on his part.
I've lost a lot of respect for Time Machine since then.
I'm not sure what your error was but it might have been for the best. If there was corruption in the backup image then you'd be complaining about how it restored a corrupt backup.
Just failing to restore is unacceptable.
I backup gmail with gmvault to a thumb drive, which I suppose is beyond many non technical people, but I'm sure google will figure out how to restore his account without much difficulty.
I wish I knew how this person knew how his password was compromised, it sounds reasonably secure.
I personally haven't plugged my iPad into my Mac in ages. Then again I've also made damn sure it's backing itself up to the cloud. I'm not sure if this is the default setting. It should be, IMHO.
(And I gotta say, it's really freeing to know that even if all my possessions are destroyed, I will have lost at most a day or so of work.)
As an alternative there is a mode where you can use your Gmail passowrd and it can be saved but this is not recommended.
Link for the lazy - http://gmvault.org/
In this case, the guy had ALL his shit wiped. Not a clumsy move at work causing months of extra work, or some dickhead hacker having some fun with your account credentials, no they actually thoroughly deleted a huge chunk of his personal data.
See it's like, if a pyromaniac burns down someone's home, maybe there were ways to prevent that, but you don't go blaming the victim then either. Some times the first thing is sympathy. There's times to be heartless and times to be not.
Remote-wiping all his personal stuff was so unnecessarily malicious, sympathy comes first. And besides, in this case, not having any non-remote-wipeable backups, the only thing you could possibly maybe blame him for is putting all his stuff in the cloud. Yeah no not smart, maybe, but it simply doesn't weigh up to the fact that someone actually went through the trouble of meticulously deleting all of it. Not stealing, or defacing, but deleting.
It's turtles^h^h^h^h^h^h^hsecurity problems all the way down…
"There are obvious caveats to this solution though. If somebody gets root on my server or access to the network, they can sniff the emails on the way in before they're encrypted. This wont help them access historical email which was encrypted before they started though. Also, if somebody installs a trojan on my laptop it's game over; they can grab my private PGP key, and use a keylogger to get the password for the key."
There is no "perfect" solution. There will always be attack vectors. I just removed a few. Specifically, compromising my email account, or compromising one of my clients (in certain ways).
Instead of memorizing horrible passwords, have you tried making a non-horrible passphrase by rolling dice and picking words out of a dictionary? Arnold Reinhold calls it Diceware:
It isn't easy to develop these habits, but my data is priceless to me. I know that too well because I've lost some of it, and it still hurts. So I've made it a tradition to chip away at it on daylight savings sundays: update clocks, check smoke detectors, work on backups, shame friends into doing same....
(Which underlines the point that you need to do backups...)
(Incidentally, you can backup and restore /data/data/com.google.android.apps.authenticator2/databases/databases via adb pull/adb push and you don't have to do the "painful" restore. It's slightly less secure, but I keep a copy on my SD card.)
PS: even if you aren't rooted, if your device can be rooted w/o a wipe, should consider yourself just as vulnerable and enable FDE as well.
The DB is a Sqlite3 database containing plaintext tokens and the account names they are used with, so while the attacker would still need your password, they can generate new tokens with that data.
Good policy upon losing any device that contains 2FA information is to use one of your backup codes to log into your account, remove the 2FA, and re-add it, thereby invalidating the old token secret. Thus, even if someone has your unprotected DB, they can't generate tokens for your account.
You really should consider using using whole disk encryption like FileVault or PGP-WDE. Encrypting a single directory or a home directory is not a good solution.
This may not be the case. Computers are very fast at checking passwords, and if Apple doesn't deliberately slow the login process for all authentication scenarios it is easy to check a lot of passwords in parallel.
I use Google apps for business for email hosting and even setup a secret email account that is used as the admin account (which can setup users and change passwords). I think most people that use google apps set up their primary email address as the admin account, but if that account gets compromised its incredibly easy to reset the password on every account on your domain.
The problem is backing up big stuff -- I've got my working docs backed up the wazoo (I can even backup large multimedia/game projects to Dropbox) but my photo and media libraries are unmanageable.
"The only secure computer is one that's unplugged, locked in a safe, and buried 20 feet under the ground in a secret location..."
-- Dennis Huges, FBI.
The same goes for USB disks. I prefer to have one of my backup drives inactive most of the time and out of plain sight (in case of theft from my home).
Because he was a mac user, he should've been using Time Machine. It can be hosted on a network partition at your home so you don't even have to remember to plug in a backup drive. And in OS X 10.8, you can assign multiple disks and it'll keep them all up to date if they're accessible at the time. So one can be on your home network, another at your work network, and yet another on a physical drive that you can keep locked away in a safe or something. Just pull it out once a month to back up all your macs.
Additionally, SD Cards turn out to be some the most resilient data storage media I've personally witnessed. Probably helped it was encased in a camera, which was kaput, but the photos on it were fine, not even data-bent.
And a year later I found in a box of my damaged CDs some more treasures on a couple of really old DVD backups that actually still worked :D (I never bothered to really unpack the boxes of partially blackened and warped CDs--there's no need in the age of MP3, and after a while you've really seen enough boxes of sooty crap smelling like burnt plastic)
My basic lesson from this is: spread your data and risks around.
Though, none of that stuff was encrypted. Just the stuff I kept online was passworded and do friends count as a two-factor auth? :-)
It's taking Apple's "Time Capsule" branding to the extreme literal sense.
As far as USB plugs sticking out of a wall are concerned, have you heard about the "USB dead drops"? http://images.google.com/images?q=usb+dead+drop
I found that grabbing an external HD and plugging it in started time machine right up. I do that every week or so.
(Which reminds me, I should go do that in a few minutes!)
So for the last 6 years or so (we've been providing offsite backup since 2001) we have offered "pull backups" to our customers that request it. We give them our public SSH key, and we log in and rsync their data back to us.
Also, RE: the previous comment about not having your data consolidated to a single provider, we run an ad on reddit regularly making the same point:
It gives me quick responses if I need to restore something, but if my house blows up, I'm only $100 and a FedEx visit away from having everything back.
Said password is therefor used a lot, with a lot of chances for interception. But most of all, it's used for trivial matters in which password typing is a nuisance (installing a cheap iPhone app), which pretty much invites people to use a weak, easy to type password.
iCloud should have multiple, completely separate forms of authentication for services like Find My Mac, instead of using the same login for wiping all your Apple hardware as you use to download Angry Birds...
Your email, contacts, calendar, location, phone security, documents, files, music, videos, games, apps, credit card details, merchant account, search history, web app hosting, etc., all on one account.
I thought about it and worried about it and thought about it some more, and finally did it.
And I had no problems at all - it works really well.
After that I turned on 2FA for gmail and facebook.
Sure, it's not perfect - but no security is. But is is definitely better than using passwords alone.
Or, what if my iCloud gets hacked and my iPhone is remotely erased, can I still access my Gmail and Facebook enough to remove my phone from them?
Google 2 factor authentication needs 3 things: your Google username, your password, and the token number generated by the authentication application. Stealing your phone gets one of those things.
You get 10 single-use codes to print out for this situation. You can revoke these code and generate new ones whenever and as often as you like.
Your concerns were all similar to what I had. Another was that I have programs that need programatic access to my Google account and I don't want to rewrite them to use 2-factor authentication. That is solved by generating a revokable application specific password.
I found that turning it on and trying it out answered a lot of concerns I had.
2 of those things, if you have an android and they're smart enough to go to Settings > Accounts
And they can get your password if you have your browser remember it.
So, potentially, losing your android could mean losing your account.
In any case, there is a fairly easy solution here: don't let your phone web browser remember your Google account password.
downgrade if you want to but it will be the day of my death when I let a provider dictate my needs and wants with its stupid rules and regulations. I pay for their services and barring unreasonable ones they have to provide what I need. And passing automated smsses are something that is not unreasonable.
One question, does it only block out of country automessages or do they also block 2FA messages of Turkish banks?
And not having the bank because I'm still waiting for a residence permit, which means I'm still doing the kontor thing rather than having a plan, something that's much cheaper with AVEA.
As a bonus, you can also use it for when logging in over ssh with password http://askubuntu.com/questions/159727/how-can-i-use-a-passco...
Anything can be hacked but it's a really solid system, even against a targeted attack and motivated attacker.
I'm aware of one incident (the Cloudflare hack), but that seemed to be more a vulnerability in the password reset functionality than the authentication mechanism.
SMS verification is less than ideal, though.
I know I have a printed sheet of one-time codes, but I think if an attacker compromises the phone number on my account, I'm screwed.
Other than stealing the phone, that is.
Personally, I only give as minimum information as possible.
Two-factor authentication (using say your phone like Google) wouldn't work however because typically it's your phone that is stolen and you are trying to wipe.
Did you mean 2 factor authentication?
Google + 2 step authentication + Yubikey
Is there any reason why you can't do this? It seems like it would work? (I've never used Yubikey so I might be missing something)
Lose your main phone? No problem, login to your account using the two factor code from your landline (or partner's phone).
Of all the issues surrounding this event, this one concerns me most. Most users would not be able to escalate like this. Hosted services need to be providing this level of support to all customers 24/7/365 - or at least offer it as a premium option.
In short: I'd advanced paid for a 1 year Apps account a month before the monthly billing came in to place. My credit card expired with 11 months of the contract left, but they suspended the account as that appears to be policy with new monthly billing system. I received no email asking to update the card prior to suspension. This suspended all the services it was connected to. Call centre couldn't help, account was down for 18h - they just said wait for new card to propagate.
I'm sure if a journalist from Gawker had posted this to HN it would have been resolved with more urgency.
Edit: Surprised to see Cloudflare is proxying their website. I understand wanting to be impartial, but I think it's fairly easy to draw the line at groups breaking the law.
I don't know what part of the world you're in, but here (in the UK) it'd actually be a criminal offense carrying a multi-year prison sentence under the Computer Misuse Act.
I'm wondering at what point the police or law enforcement get involved in the US?
This is the only case I can think of where non-classified information leaks were prosecuted: http://en.wikipedia.org/wiki/Sarah_Palin_email_hack (There are probably more, but I can't imagine any would actually disprove my point.)
Brute-forcing the iCloud password is an online attack and would probably (hopefully) be caught by apple.
What is more likely is a keylogger or similar malware at which point even a longer password would not have helped. The days where macs are free of malware are unfortunately over.
This is just speculation.
When I just did this for my own account, the first security question is your date of birth, which is easy to find for anybody via Facebook. The second was a generic security question.
These are easy to guess or to find out via social media. You could spearfish a user by sending them a free account to a web service and asking them the same security questions on registration.
The security isn't adequate, considering the data that is held behind an Apple ID. I also can't believe they have a delete feature that can not be undone.
For my own account I have done a few things. First I have a secret email address for online accounts that require higher security. These emails are unique for each service and are not published anywhere. I have also removed all of my personal information from my social accounts, such as date of birth, name of school, etc. and my security answers are always random strings.
The other option is that malware was used, or a transparent proxy. If iCloud doesn't verify the server certificate it would be straight forward to proxy the HTTPS requests. iCloud will also always send out connection attempts every x minutes, so if you accidentally connect to a public WiFI hotspot or personal network with an intercepting proxy setup, you can have your password stolen in a matter of minutes.
I am also not super-confident about two-factor auth. I noticed that with Google Apps the verification SMS messages can be read using the web interface for my telco provider. A web interface that is protected by nothing more than an email address and password with the same weak security questions.
I think it is very feasible to hack around second-factor SMS notifications by first hacking the telco provider web interface and reading then deleting the SMS alerts. You are only as secure as the weakest link in the chain.
While google DOES have an SMS seconds factor, I highly recommend use their Google Authenticator app  instead, which generates the code directly on your phone, sans network communication.
I've always used a pseudo-password (i.e. it's a standard response of mine that isin't related to the question) for security questions given how weak they are.
I do believe though that sending a password "in the clear" over SSL is totally sufficient. SSL was designed exactly for sending sensitive information like passwords.
We can't blame Apple for not designing a protocol (it might be just plain HTTP basic over SSL) with people in mind that turn off SSL security in order to get access to paid content without paying.
I was voicing this exact concern here: https://news.ycombinator.com/item?id=4240124
I think it would be a great improvement to have some kind of challenge-response nonce/timestamp hash thing going. So that even if the plaintext of an SSL connection were to be revealed at some point, you couldn't deduce the password-equivalent.
The problem with challenge/response and nonces is that the server and the client both need to have access to something secret to encrypt the nonce with. This usually means storing the plain text password on the server or at least a hash of it which then would be used to encrypt the nonce.
But this also means that when your user database gets lost, all accounts are instantly compromised without the attacker having to do any kind of brute-forcing.
Unless you notice an intrusion immediately, the damage that can be done in such a configuration is way bigger than if the server gets the secret thing from the client and does the hashing there, because now an attacker has to individually brute-force the various accounts (keeping at least those who chose a strong password safe).
Even if perfect forward secrecy was not doable, I assume it's far less likely for an attacker to brute force my SSL private key than it is for them to acquire my user database - not that I want that to happen of course.
Anyways, your suggestion sounds much better than my initial nonce suggestion. :)
To be clear, the password was unique. I use 1password as a password manager and even double checked to make sure that I wasn't using it anywhere else.
FileVault2 should take care of the theft problem anyways.
Too bad you can't partially-enable Find my mac for the location service, while disabling the remote wipe and lock services.
On current Macs, a live USB stick might be a better idea than a live CD. Or even better a bootable backup created with Carbon Copy Cloner (CCC) or SuperDuper.
(this is less of an issue if you're encrypting everything)
Give them enough access to get on the internet & use the machine. Keep my files stored in my own account.
The internet, like a car, somehow makes people feel like they have an invincibility cloak on that lets them behave badly.
The "nicest guy" would not use language like "bitch" or "fag" in comments (to pull the first example I saw in that post's responses), because this implies an assumption that comparing the target to a woman or a gay man should be received as a deeply cutting insult. And this alone acts as enough of a cover for me to judge that book, really.
No, these are in fact rather horrible little people, and it wouldn't surprise me if they were in league with the perps who erased this guy's stuff for teh lulz or whatever.
But to clarify my earlier point, if the nicest guy can turn into a bad person on the road, imagine what a not-so-nice person can turn into.
...could mean anything from myacct1 to iS2xd45
Since the password is no longer in use (only assuming), it would be interesting to know what it was - perhaps the reason that it was hacked was that it simply was easy to brute force due to common dictionary words?
Just throwing an (possibly wrong) idea out there.
Without knowing the guy, I strongly suspect a reused password that was exposed somewhere other than Apple/iCloud. Anyone want to bet against this Gizmodo guy's password being in the Gawker password dump?
Security is only as strong as the weakest link. CloudFlare was hacked recently because the attacker was able to redirect voicemail to another account, then use the two-factor backup recovery phone option to take control of Google Authenticator.
Hence, a usability nightmare.
I saw many people buying their apps in public and the password input in iOS isn't really secure from bystanders. As a Gizmodo reporter he probably went to dozens of events where he was pitched to try someone's app and maybe even given App Store codes. If he used to download apps on such events that might be the source of his leaked password. Someone could simply see what password is he typing.
As long as Apple requires you to type the password with each purchase, it is wise to separate your sensitive data/services with the App Store credentials.
For such a customer focused company, it just seems so bad.
Assuming the answer is no, there are only two remaining alternatives: 1) Someone targeted and keylogged him to obtain the password, in which case it doesn't matter how strong the password is; or 2) Someone hacked iCloud itself and stole their (presumably unsalted) password file.
In that case, yeah, a stronger password might've helped. Bad user. No cookie.
But if he thinks he's having a rough night, consider what scenario #2 would mean to Apple. The impact of an iCloud hack would be measured in multiple billions of dollars of market capitalization.
There's another possibility: he re-used his iCloud password on another account, that was compromised, and someone tried that successfully against his iCloud account.
The bigger issue, as someone else has said, is putting so much remote control behind a single point of security.
Typing-the-most-common-passwords-with-numbers through the interface style. Basically guessing from the top password list.
The possibility is a bit far-fetched, but it exists. The likelihood that this was actually the case is extremely low.
From the post:
> My password was a 7 digit alphanumeric that I didn’t use elsewhere.*
It sucks, but when you've got control of someone's iCloud account (email, and remote wipe of presumably their primary devices), you've put them in a tight spot. One of the many reasons that I use iCloud for my phone and iPad, but certainly not my primary machines (or email).
I was shocked, mostly because the price was fairly inexpensive, and her lot love to spend lots of money on small things.
I take pictures with my iPhone. =/
How can a system allow login attempts so fast and often that a 7 digit word with numbers can be hacked?
That's hundreds of thousands of attempts.
It wasn't brute-forced, unless somebody got their hands on the iCloud password database.
As for linked accounts, that again is another education many of us have probably overlooked and I would say if you do have a 2-factor facility that uses SMS, maybe think about digging out an old phone and getting a PAYG SIM with a token credit and using that number. But security is a never ending drive bordering on paranoia and in that you do what is enough to help you sleep at night after reading the article.
Don't think I have seen a article doing a test on how easiy it is to recover a hacked account and how long it takes. I certainly have never seen any speed comparisions, nor consumer reviews in that area. Anybody know of any at all?
Data: Back it up. Backup your backups. Stop fucking around. If you don't get hacked, your storage will fail.
Software: Don't install shit you don't trust. Don't trust shit you can't verify.
Passwords: Don't try to remember them!!
It's 2012, not following these simple rules is inexcusable.
Write it down on a piece of paper (or use a password manager that will show your password).
Back in the 1990's "writing down passwords" was considered a huge security hole.
Now day's attack vectors have changed and it is probably more safe than using a memorable password.
The alternative seems to be to have all those devices "remember" my AppleID password, which seems like a security lose.
If your devices are physically safe, and iCloud has remote log-out (does it?) then this may be more safe too.
Write the strong password on a credit card sized bit of paper, and keep it in your wallet.
People tend to keep their wallets safe.
Most people can learn complicated passwords after a few days or weeks of use, so you can keep the paper in a safe place at home once you've learnt it.
The truth is that 2-factor authentication is the real solution. But one has to make do with imperfect solutions
Writing your password / passphrase down allows you to chose a good, strong password. You do not give anything that links that password to a particular service.
Most people will only need to refer to the written password for a week or so, and then they will remember it.
You put the piece of paper in the wallet because you want people to treat it like a 50 dollar bill. People leave bits of paper anywhere, but they don't leave 50 dollar bills everywhere.
Not writing down the password? Yeah, we see how well that works. (https://www.google.co.uk/search?q=most+popular+passwords)
It is baffling to me that authenticating to computers, software, and services is still so weirdly broken. Especially since there is now billions of dollars involved in it.
1) I have to lose my wallet and
2) Not change my password and
3) You have to know my login email address and
4) You have to find which service the email and password work for
...and all of these have to happen in the time between setting a new strong password and learning that strong password. Because when you've learnt the pass you stop carrying it around.
If you lose your wallet there's a bunch of stuff you need to do. You need to cancel your cards, for example. Keeping a single password in there (for the short time it takes you to remember it) means that there is one more step added - you need to change that password.
You're also failing to do a sensible risk analysis. The threat model for passwords is "hackers, anywhere in the world". The venn diagram of that very big set has a teeny tiny intersection with the much smaller set of "people who have access to my wallet if I happen to lose it".
Writing down a good password means that you get to use a good password. You get to choose a properly strong password, with many characters of mixed case including numbers and specials; or a 6 word passphrase.
If you're worried about someone stealing it, just shift the password over, so it's now "mQWhXnLv0qzi1h1 > 1" on paper.
The kind of weak encrypting scheme you can remember is easily defeatable, this is still very vulnerable even if you leave one or two letters off (which you'll have to remember in addition to the scheme). So, going back to the parent, no, this isn't safer than a password in your head.
Obviously this is still less secure than no password in the wallet at all, but I don't think it's "very vulnerable" as you are claiming.
having a 20-30 character long password is fairly easy, it may not be 100% random, but (correct me if i'm wrong) a password that long with just a handful of random extra letters and numbers is going to be rather easy to remember and probably going to be just as had to brute-force.
Thus, option 0ption opt1on etc all get mangled into a wordlist, while )*&HD@IHU don't. Yes, it still increases difficulty, and they are much easier to remember, but people need to be careful.
This one is pretty tricky. There's a lot of little tools out there that I find invaluable, and haven't screwed me over yet (as far as I know), but fall firmly in the "downloaded it off someone's little personal website" category.
I'd say we need better fine-grained permission systems for software, so people can install programs without needing to trust them, safe in the knowledge that they'll get the opportunity to deny any malicious behaviour before it actually happens.
That's exactly what I mean. I envisage something kinda like Windows 7's UAC dialogs, but more specific than "this program wants root! [allow] [deny]" -- more along the lines of "this program wants to install a driver / write to such-and-such protected files (its own program folder/anywhere in Program Files/the Windows folder/...) / low-level disk access / to run at startup / etcetc [allow] [deny]".
Actually, I'd specifically forbid "all permissions" as an option; an enumeration of every permission a program wants would make the user more likely to notice unreasonable requests than a single item would, even if that single item's actually "everything". I get the impression, from seeing ordinary users dealing with UAC, that they don't usually appreciate quite how much power they're giving programs when they hit "allow".
I believe that's similer to what SELinux does, although I've never used it beyond observing its presence on university-owned computers.
Put all your eggs in one basket and then watch that basket.
What do people like for backups these days? Crashplan seems pretty damn good to me.
They've made an awesome product and they provide it at an awesome price.
Previously, I was a user and big proponent of Jungle Disk, but that product has become all but completely abandoned since being gobbled up by Rackspace. (I love how their solution to comments about going radio silent and not updating their blog in over a year was to just take the blog down and put up a "The Jungle Disk blog is currently unavailable" message, as if the blog were just temporarily offline. One of their last blog posts was a "Future of JungleDisk" post, outlining tons of features that, 16 months later, were nowhere to be seen).
I had been recommending Carbonite to friends and family for an easy-for-normal-people backup solution, but their performance falls short of CrashPlan, and their heinous near-silent default exclusion of video files from backups would have led to serious tears if we had ever actually needed to restore from backup. (Automatic backing up of video files is reserved as a feature for the new $150/yr HomePremier plan - which at least now makes this fact somewhat visible. Previously, there was damn little to indicate that this exclusion was happening). That made Carbonite something much less than the "set it and forget it" backup for my non-technical friends and family that it was supposed to be.
CrashPlan is nice and friendly, has no hidden "gotchas" that I have found yet, and has a great PRO service as well. The client GUI can even be made to connect to the daemon on a headless server through an SSH tunnel, just with a simple change in port number in the config and forwarding the remote port through the tunnel.
And after you've logged in to Crashplan, it's not clear to me that you can do a whole lot of damage via the website; the password used to encrypt your data is specified on the client side, and there is no reset mechanism for it. I mean, they could update the credit card settings, or modify the configuration options like excluded directories or send rates, but not a whole lot else.
Also, you can just specify your own encryption key. Everything is encrypted locally.
It seems like they should be holding on to files for 30 days period or something. Does anyone know?
(I do like CrashPlan, but this seems to be common practice with data storage services.)
Removing the computers associated with a CrashPlan account and then cancelling the account looks like it'll cause a pretty big headache.
Backblaze really shines if you have a single Windows or OS X PC with a lot of data. For $50/year, it will allow you to backup unlimited data for a single computer. As far as I know there is no student discount.
SpiderOak really shines if you have multiple Windows, OS X or Linux PCs with a small amount of data between them. For $100/year, it will allow you to store up to 100GB of data between as many computers as you want to back up. If you're a student, it will only cost $50/year.
"Wuala is completely private and secure. When you store a file in Wuala, the file [..]gets encrypted before it leaves your computer. [..]Your own password is very important here: it never leaves your computer, so we do not know it. Hence, not even we can access your data."
But it seems pointless in light of:
"Do you plan to open the source code?
Currently not. Opening the source code of Wuala would consume quite some time and effort, and commitment to maintain it. If you are a software engineer and would like to see how Wuala works, feel free to apply for a job at Wuala."
It would be trivially easy for them to hide a backdoor and/or leak data in their closed-source code. So at the end of the day, the message is "Trust us." So what purpose does the client-side encryption serve? Empty marketing. At best, it makes it _slightly_ harder for them to read your files.
Tarsnap (www.tarsnap.com), which does have client source code available, doesn't suffer from this problem. Unfortunately it's a fair bit more expensive.
Also, please note that laws are often constructed such that companies can be forced to hand over data they possess, however not to collect data they do not possess yet. E.g. there are many laws in many jurisdictions that could be used to force Google to hand over data you have stored in Google Drive, but the same laws cannot be used to force us to add a backdoor to Wuala. So legally, it is much much easier to obtain data stored in Google Drive than to obtain data stored in Wuala (or another service that uses client-side encryption). Noone has ever asked us to add a backdoor to Wuala and we would fight against it if someone did.
I agree that it would be nicer to open the source code so our security would be independently verifiable, but claiming that what we do is "empty marketing" is clearly wrong.
For why not to trust a closed-source system's claims of security, see Skype. If I remember correctly what I have read, they boasted about using "end-to-end encryption", strongly implying that your Skype calls could not be wiretapped. The catch? The encryption keys were stored on the server! And there was a story where someone (a drug smuggler, I think) was busted seemingly as a result of intercepted Skype calls. The misleading claims of security didn't ruin Skype's reputation - people still use it.
I'm glad you replied to my comment as it shows you're at least thinking about these things. I hope you will consider opening your source code in the future. At that point Wuala might be of interest to me.
Full story, from last fall: http://prog.livejournal.com/983354.html
I'd be curious to hear more about other people's solutions.
Maybe there should be a significant time period (hours?) after a password change where this functionality (and any other data-destruction functionality) is disabled. Or maybe a password change should require you to re-auth every device before data remote deletion features can be used on it.