The,best,online,backup,service,for,securely,encrypting,your,data

Many people resist backing up their data to an online backup service like MozyHome, Carbonite, or Backblaze because they worry their data will be poked through by company employees, hijacked by criminals, or provided to law enforcement or government agents without due process.

The sanctity of your data boils down to whether the encryption key used to scramble your data can be recovered by anyone other than yourself. Below I outline the various methods and levels of encryption that can be employed by these services, and then evaluate six of the best options for home users. Several give subscribers full control of their encryption. If you’re already using a service, it’s possible you can even upgrade to take advantage of greater ownership options.

Choosing the services to evaluate

These are the parameters I set up for this roundup:

• Focused on services that offer a personal edition, where you can purchase an account for a single computer or a bundle for a family
• Included services that are established or well-reviewed.
• Excluded services that offer scant information about their security and encryption practices. Subscribers should always be privy to how their data is protected.
• Excluded sync services, even those (like SugarSync) that offer continuous backup and versioning. I define a sync service as one that doesn’t encrypt data with a per-user key before being transmitted over a secure connection. That also leaves out Box, Dropbox, iCloud, Google Drive, and others.
• I also bypassed services that offer bad advice about file retention or security practices, and ones whose information is years out of date.

Six companies remained after this winnowing: Backblaze, Carbonite, CrashPlan, iDrive, MozyHome, and SpiderOak ONE. Keep reading to see how they rate on encryption features and strength.

Encryption: The ins and outs

Internet-hosted backups have several points of failure where encryption can protect a user’s data. I evaluated the services on each of these points:

Key possession. Encrypted backups require someone to create and possess the underlying key that’s used to encrypt your data before being stored by the host. But there are several aspects to this:

• Who creates the encryption key? In all six cases, the native desktop backup software handles key creation, but with two services, you can opt to create a key.
• Does the backup host hold the key in a form it can directly access, or in “escrow,” where it’s protected by a passphrase you set and the host doesn’t know? Or does the host never hold the key at all?
• Is the passphrase converted through an algorithm into the actual encryption key, or is the passphrase used to unlock the encryption key? In the former case, an attacker who recovers the passphrase also effectively has the key, and can decrypt your backups.

If a backup service lets you reset your account password without losing access to your archives, it has full access to the encryption keys that guard your backups. If it can’t access your files’ contents (and sometimes even the listing of files) unless you enter your password or a custom key, you retain control.

Diversity of keys. Each service varies in whether it uses a single key for all backups, or various keys for different tasks. For instance, CrashPlan uses the same encryption key to scramble all backed-up files across all sessions; Backblaze generates a new key for each backup session; SpiderOak ONE has unique keys for every folder, version, and individual data block within its backups, partly to enable a group encrypted sharing option.

The more unique keys are used, the less risk you face from a single leaked or cracked key, or from advances in cryptographic cracking.

Encrypted before transit. Hosted backups require native apps to scan drives for files and transmit them. Strong encryption should be used by the app before files are transferred to a hosted service.

Encrypted in transit. It’s vitally important that transferred data is strongly protected separately from the encryption that wraps data before it’s sent. That’s to guard against offline attacks, where someone can intercept encrypted data and then attempt various ways to break it, both now and in the future. Encryption that’s unbreakable in 2016 may still break in the future.

Protected at rest. Even encrypted data needs additional layers of security. Some hosts disclose additional information about how they safeguard your data, including certifications and audits from third parties.

Restoring files. When you restore a backup, there’s also a question of where the key winds up. Even for services that allow a user to create a custom full encryption key, that key has to be transmitted to the backup host in a form that can be decrypted in order to restore files.

With all that in mind, we evaluated the following services from Excellent to Poor, summarizing their best and worst points in the pros and cons that follow each rating. For services that offer multiple ways to set up security and privacy, I’ve ranked based on the best method available, as outlined in the section above.

Backblaze

Encryption rating: Very good

Pros:

• Data is encrypted before and in transit
• Website lets you access encrypted backups
• Platforms: OS X, Windows, iOS, Android

Cons: 

• Password is transmitted for recovery
• Lacks a client that can restore and browse with local encryption keys
• Unique keys can be unlocked with passphrase for master key

Backblaze uses public-key cryptography—the same kind of encryption used widely across the internet, including web connections with SSL/TLS cryptographic protocols. The app creates a public-private key pair and transmits the private key to its servers. For each backup session, Backblaze creates a new strong session key, and uses the private key in the key pair to encrypt it and send to its servers. The key is only stored in memory on the client and never stored in the clear at the server.

However, you can opt to set a passphrase to encrypt the private key before it’s transmitted to the server. In that way, this master private key and each session key are held in escrow. Only someone with the passphrase can access the private key, which in turn can decrypt a session key that restores data associated with a backup session.

Backblaze has engineered its system so that restores all happen via its website, not in the native computer app, so you have to enter that passphrase to decrypt the private key. The passphrase is also required for viewing information about backups through its website and mobile clients. The private key is also held only in memory on its servers and dumped when file browsing and restore operations finish.

This isn’t ideal. Backblaze falls short of other backup services by not offering a client that can handle restoring and browsing with encryption keys kept entirely locally. And while each backup session has a unique key, the fact that all can be unlocked with knowledge of the passphrase used to protect the master private key makes that less impressive. In practice, you’re more secure if you never restore files or browse lists.

Carbonite

Encryption rating: Excellent on Windows, Poor on Mac

Pros:

• Data is encrypted before transit with Private Key encryption for Windows users
• Website lets you access encrypted backups (only through Auto option)
• Platforms: OS X (limited), Windows, iOS, Android

Cons: 

• Data is encrypted before transit with Private Key encryption for Windows users, but not with Auto Encryption (Mac users’ only choice)
• Mac users get a server-side key that’s stored on the server

Carbonite is a mixed bag. It offers only Windows users the opportunity to passphrase-protect a private key. Mac users rely on a server-side key that’s generated and stored there. Worse, Carbonite doesn’t encrypt Mac users’ data before transmitting it with its default Automatic Encryption option; it encrypts only on the receiving end. That’s not the case with what it calls Private Key under Windows.

Because encryption happens on the far end, restored files are also decrypted before being transmitted back to a Mac user. Carbonite should step up and provide Private Key for Mac users, as the current situation doesn’t meet the bar for robust protection for backups or restores.

CrashPlan

Encryption rating: Excellent 

Pros:

• Data is encrypted before and in transit
• Password is not transmitted for recovery
• Website lets you access encrypted backups
• Platforms: OS X (Java app), Windows, Linux, iOS, Android, Windows Phone

Cons: 

• The archive key reset via reminder question is not a secure method
• CrashPlan for Home requires a Java app, with security, reliability, usability issues

Code42’s CrashPlan offers three distinct options for setting up password and key control:

• Standard: At the basic level, Code42 maintains on its servers an encryption key generated by its backup app. Your password manages access to the account as well as tasks like adding computers, using mobile clients, and restoring files.
• Archive key password: The CrashPlan client generates a key, but you set a separate passphrase to encrypt the key, which is then stored in escrow at CrashPlan’s servers. You can upgrade from Standard to Archive without dumping existing backups. The archive key can be changed. There’s even an option to add an archive key reset with a reminder question. This reduces security enormously, however, because it effectively means your easier-to-remember answer is now the weakest link in accessing backups. I recommend against using it.
• Custom key: You generate a lengthy key in one of several methods that’s never stored in any fashion at the Code42 servers. This custom key option is unique among services surveyed—all others rely on either a key generated by the app, which a user may be able to escrow at a server, or use an algorithm to convert a passphrase into the encryption key. If you switch from standard or archive key, your previous data is dumped, and you can’t downgrade encryption of newly archived files.

CrashPlan can decrypt files entirely via its native app. The archive key or custom key need only be entered when restoring files via the web interface, or viewing files via the web or the mobile apps.

CrashPlan for Home still requires the use of a non-native Java app, something that’s been a security, reliability, and usability sticking point for its customers for years. Even its business services have moved to native apps. Java has many known security issues, but CrashPlan relies on it for a self-contained app, rather than any web-based interaction.

iDrive and MozyHome

Encryption rating: Fair 

Pros:

• Data is encrypted before and in transit
• Password is not transmitted for recovery
• Website lets you access encrypted backups Platforms: OS X, Windows, Linux (iDrive only), iOS, Android

Con: 

• Passphrase conversion carries some risk

These two separate services work in nearly an identical way. Both let a user create a passphrase—iDrive inaccurately calls it  a “private encryption key”—which is transformed through a cryptographic algorithm into a 256-bit encryption key.

When you use this option, neither the passphrase nor the resulting key gets transmitted to the service. Both iDrive and MozyHome also admirably handle decryption in their respective clients without sending the passphrase or key to a remote server.

Even though the key is never sent (good), this passphrase conversion approach is weaker (bad) than a passphrase that locks a separate encryption key. That’s because an attacker only needs to obtain your unencrypted passphrase or break it through brute force to have access to your key. With that, if they can obtain your backup archives from the services or capture them in transit somehow, they can decrypt.

While that scenario sounds unlikely, there have been exploits in the past that allow crackers to break encrypted data transmission. When a passphrase locks a separate encryption key, an attacker might need to obtain your account name and password and the passphrase, and then would either have to break into the backup service’s systems or log in directly and use the backup service’s interface to retrieve files, leaving a trail.

SpiderOak ONE

Encryption rating: Very Good 

Pros:

• Data is encrypted before and in transit
• Password is not transmitted for recovery
• Website lets you access encrypted backups
• Highly granular shared secure data areas
• Platforms: OS X, Windows, Linux, iOS, Android

Cons: 

• If you want to share files or use the website, you have to enter the password

SpiderOak ONE is a bit of a hybrid between the iDrive/MozyHome and Backblaze approaches, and its sole method is highly secure—there’s no account password-only default tier.

With SpiderOak, you create a password in the desktop client, and the software derives many, many encryption keys from that. The password is never stored or transmitted to SpiderOak, but the keys—generated uniquely for each data block of the backup, each folder, and each file revision—are wrapped in a layer of encryption and stored on the backup servers.

This is because SpiderOak offers highly granular shared secure data areas, which require storing encryption keys on its servers in such a way that permission can be granted to multiple accounts to access files and folders. The same key can effectively be available to different users without storing it in such a way that SpiderOak (or a third party) can gain access.

In normal backup and restore operations, your password is never sent or used by the SpiderOak servers. However, if you want to share files, use the website for access, or use mobile clients, you have to enter the password to unlock access. As with other services, the keys generated from the password are stored in memory only while being used, and then flushed.

source”gsmarena”