Hacker News Reader

Comment by jwr | Hacker News Reader

What's even more important, you will be able to encrypt your backups without having to disclose the encryption key in case you ever need to restore (client-side encryption and decryption). This is not the case with Backblaze, which is why I switched to CrashPlan — but I'm still looking for other solutions.

View on HN

CrashPlan shows your encryption key in plain text. Doesn't that worry you?

Where does it show that? And are you sure we are talking about the encryption key, not the account password?

Settings / Security / Archive Encryption / 448-bit encryption with custom 448-bit key

Then no, it does not worry me. Obscuring password entry in an application that I almost never run is not a problem. Plus, if I do actually run the app and want to enter the password, I don't do it with a bunch of people peering over my shoulder.

CrashPlan defaults to using the account password as the encryption password.

However, you can also secure the encryption with a password not associated with the account. Or even provide your own 448-bit key. If you do either of these options, CrashPlan support will not be able to help you

This setup allows CrashPlan to easily help non-technical home users, while allowing technically savvy users to securely hang themselves with their own encryption.

My question is not about the setup, that's OK. I am wondering why CrashPlan shows the encryption key in the clear and does not store it in the user or system keychain.

I see what you mean. I have up voted your original comment.

I'm assuming this because their desktop client is a java app and it it's been made to run on linux, mac and Windows. Is there such a thing as a keychain on Windows? I've only used it on linux and mac.

Yes, there's the CredWrite API - http://msdn.microsoft.com/en-us/library/windows/desktop/aa37..., although I must admit I like the OS X keychain a lot better.

As others have noted, it is partially because Crashplan is a Java based app. Partially, it is also because Crashplan runs as System, not as the user. That way, I can have Crashplan backup my wife's user account and my user account.

Furthermore, you can use the encryption key + a custom password, or your own encryption key with a passphrase. In this case, it is encyrpted locally and the key is not sent to Crashplan[1].

[1] http://support.crashplan.com/doku.php/recipe/change_security...

You'd prefer that they lie to you and pretend it's not stored in the clear? If you don't have to type it in every time a backup runs, it's in the clear - everything else is just window dressing.

Standard practice is IMHO to use the user or system keychain.

Right, which is a largely meaningless distinction: if the process runs as you, any successful attacker can simply read it out of the CrashPlan process in memory.

Again, if you're not typing the password in every time, a local compromise is almost certainly game-over. Apple's keychain helps reduce the damage if the data's not actively used but for something like CrashPlan which is always running the attacker is probably going to be lucky.

I agree that showing the encryption key in the clear is not a serious security flaw but it's IMHO against best practice.

Passwords and key are usually shown in an obscured form, usually with asterisks, and stored in the user or system keychain. You are absolutely right that the security value of these standard practices should not be overvalued but still … what else within the security framework of CrashPlan is not done in accordance with best practice?

(I assume, BTW, that CrashPlan does not use the system or user keychain on the Mac because it is not a real Mac citizen but a Java-based app. Firefox and Wuala – the latter Java-based too – don't use the user or system keychain either.)

There have been sound arguments made against obscuring password entry.

Those arguments are typically made from the wrong perspective. It's just so common that if you don't do it, your product will be perceived as insecure. And as long as actual security is not horrible, the perception of security is what drives sales, not the actual security.

The other feature that's great about CrashPlan is that it will allow you to backup to other systems running their software. I backup my laptop to both their service and one of my dedicated servers. That way if anything ever happens to their online service I have a second remote copy that I control.

Backblaze does support the optional use of a separate encryption key which they claim to never store, but there's no information about whether it is ever disclosed to them or not. There's little information on their website, but it can be set in Settings > Security in the Backblaze client.

You have to provide your encryption key to their website if you want to recover files. That's a show-stopper for me.

Reply on news.ycombinator.com