forumsraka.blogg.se

1. #Update crashplan archive
2. #Update crashplan software
3. #Update crashplan code
4. #Update crashplan password

#Update crashplan password

#Update crashplan software

They still store encrypted data on their servers, but if you want to see it in the web interface then you need to provide their software with both the certificate file and the certificate password. This means that Code42 does not store their certificate on their servers. Basically, breaking your certificate password is likely fairly easy if someone is really motivated and you didn't choose a good password. If anyone gets their hands on that file, the the only thing stopping them from using it is your certificate password, so if you made it hunter42 you're pretty screwed. As I mention above, your certificate is a very big password.You trust Code42+employees not to give your certificate file or password to any agency (such as a government) that requests (e.g.You trust Code42+employees not to ever store your certificate password insecurely.You trust Code42+employees to store your certificate securely.

This is why the CrashPlan web interface can allow you to browse your data - after you provide the certificate password, their software can access the data using the certificate. When you provide your password, these certificate files are themselves decrypted, and are then used to decrypt your raw data. Most CrashPlan users likely use what is called escrow certificate storage, where Code42 stores the certificate files for you in encrypted form. This certificate file is commonly encrypted, just to ensure that a quick copy of the file is not enough to access the data-you need the certificate file password too. In this summary, you can think of a certificate as basically a frigging huge password stored in a file with your name attached to it. Probably yes, unless you're a high-profile target.ĬrashPlan either encrypts data using password protected certificates, or no encryption at all. If you were using Dropbox (a company which admits that 5% of their employees have access to the data stored by users in order to maintain and troubleshoot!) then encryption is pretty much essential for anything more than your shopping list, but I would be inclined to trust services which offer encryption as part of the package).

#Update crashplan code

If you are a lawyer, or have medical-related information, then you might have a legal obligation to double-encrypt, or perhaps you can get some sort of legal reassurance from Code 42 that the encryption can be trusted for that kind of data (perhaps you'd have a duty to do that in such a situation, I'm not sure- haven't personally come across this kind of data at work yet). If you had a small text file with domain administrator passwords and can't sleep at night without double-encrypting it, that's fine, but you'd want to avoid any massive encrypted files (TrueCrypt or otherwise) as the impact on performance will be an increase in network bandwidth, and much slower backups- all for an increase in security you (arguably) don't need. I would be inclined to trust CrashPlan's encryption (you've got to trust the encryption of these services or find one you DO trust).

#Update crashplan archive

So, if you add a single extra period to one of those Word docs, then re-save, your TrueCrypt archive file is now ENTIRELY different, and the WHOLE thing has to get backed up again. If you encrypt a 1GB folder, which contains numerous tiny Word documents, suddenly all you have is a 1GB homogenous blob of data that can't be efficiently handled by your backup software. I am a TrueCrypt user, but if I was using CrashPlan I would definitely avoid encrypting my data with another product before feeding it to CrashPlan to handle then push over the internet (as the performance would most likely go from good -> painful).