Underscore Backup is built to not rely on the security and integrity of any given backup destination as much as possible. It is assumed that where you place to decide to store your backups is not necessarily a trusted environment and could be accessed and potentially tampered with by untrusted parties such as system administrators or service providers.
Information herein relates to backups taken by version 2.0.4 or later of the client software.
General assumptions
- The system where the backup is running is trusted. Even though the private key for the backup is never stored on permanent media this system will contain an unencrypted set of metadata for the backup.
- User will always use a trusted and official version of the software.
- The private key password is kept secret from any adversary.
- Advances in cryptography or computing power do not compromise any of the encryption primitives used such as Argon2, AES-256-GCM, SHA-256, and SHA3.
Security guarantees
- Encrypted contents of a backup cannot be accessed without the private key password. This includes both file contents, filenames, and directory contents.
- All data is authenticated with the private key password. Any tampering with the backup from outside the system where the backup is running will be detectable.
- Any data that has been tampered with will not be decrypted.
Potential attacks
An adversary with access to your backup destination could.
- Attempt to brute force your private key from your public key and Argon2 hash. Make sure you use a strong password. As a mitigation, the Argon2 hashing algorithm is specifically designed to be hard to brute force even with specialized hardware.
- Estimate the size of the backup from the size of the stored data in the backup destination.
- Delete data. As mitigation, either back up to multiple destinations or use a destination that does versioning or does not allow deletion (Such as S3 for instance).
An adversary with network access could.
- Attempt a DOS attack by preventing traffic between the client and service.
- Infer backup size by observing network traffic.
- Determine where you are storing your backups.
- Determine from where you are creating backups.
- By default, the application will have deduplication across sources enabled. This means that an attacker with the same data can infer if you have that data in your backup for large files (Roughly more than 8 MB). This behavior can be disabled by setting the global property
crossSourceDedupetofalsein the Settings page of the application.
An adversary with access to the system where the backup is running would be able to.
- Delete data from the destination. A possible mitigation is to use a destination with versioning or deletion protection.
- Write corrupted backup information.
- Compromise any part of the backup system by modifying binaries, and intercepting passwords and private keys. However, an attacker would not be able to access decrypted backup contents from the destination unless the user was made to enter the private key password for the backup since the private key of the backup generally does not exist on the host except when needed.
An adversary with access to your backup password could.
- Access any data in your backup. You can however re-encrypt using a new master private key using the command line
underscorebackup change-password --force. Just changing your password either through the UI or without the--forceflag will only change the password and not update the private key.
UI access considerations
The UI by necessity is served using a non encrypted connection to the browser since it is not possible to generate certificates for localhost connections. However, all communication with the service using the API is both authenticated and encrypted using PFS based AES256 encryption which should stop any passive monitoring of data. This is not secure against man in the middle attacks, however given that the communication is on your local host the risk only exists if your local system is already compromised. Finally when using UI authentication this is based on the knowledge of the public key as derived from the private key password. The private key is not stored in memory, not is it transfered during the call as part of the authentication process.
Service-specific considerations
Using service accounts
Using service accounts does present an additional attack surface for an adversary.
An adversary that gains access to your service account could.
- See the service storage usage of all the backup sources tied to your account.
- See the location of any backup sources that bind to any interface (Not the default).
- See if the service is used for storing at least part of the backup.
- If private key recovery is enabled for a source an adversary would be able to access the backed-up data. If private key recovery is not enabled this would not be possible without also having access to the source private key password.
An adversary that gains access to the service could.
- See any sources and accounts in the service, including their storage usage and shares.
- Access any backup data where private key recovery is enabled and the adversary manages to guess the email of the account. An attacker that also manages to break into the billing system of the service will be able to access any backup data that has private key recovery enabled and billing emails enabled.
- Delete customer data from the back end. For the paranoid, the mitigation is to use multiple different destinations for your backup data.
- Corrupt customer backup data (It would be detectable, but potentially unrecoverable).
There are many levels of protection to ensure an adversary will not achieve this and in the unlikely event that they would, the impact would be limited to a smaller blast radius. However, due to security concerns, these will not be detailed here. The list above lists the absolute worst-case scenario though.
Private key recovery
If private key recovery is enabled this represents a convenience that comes at the cost of some security. For additional security when key recovery is enabled then disable billing emails. In this case, the email for the account is not stored anywhere in the service and it is required to access the private key recovery (The private key is encrypted with the email as the password in this case).
