5 ms·

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

• jwr 14y ago
  Where does it show that? And are you sure we are talking about the encryption key, not the account password?
  • chmars 14y ago
    Settings / Security / Archive Encryption / 448-bit encryption with custom 448-bit key
    • jwr 14y ago
      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.
• leejoramo 14y ago
  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.
  • chmars 14y ago
    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.
    • leejoramo 14y ago
      I see what you mean. I have up voted your original comment.
    • res0nat0r 14y ago
      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.
      • voltagex_ 14y ago
        Yes, there's the CredWrite API - http://msdn.microsoft.com/en-us/library/windows/desktop/aa375187(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa37..., although I must admit I like the OS X keychain a lot better.
    • varikin 14y ago
      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_settings http://support.crashplan.com/doku.php/recipe/change_security...
• acdha 14y ago
  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.
  • chmars 14y ago
    Standard practice is IMHO to use the user or system keychain.
    • acdha 14y ago
      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.
      • chmars 14y ago
        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.)
        • greedo 14y ago
          There have been sound arguments made against obscuring password entry.