Security

How NeverWiped protects your backups, stated plainly. No certification is claimed: we describe what the system does, and what it doesn’t, including its known limits.

Encryption

• Backups are encrypted on your server, before they leave it, by restic (open source) with AES-256 and Poly1305 authentication.
• The repository key is generated on your server, in /etc/neverwiped/repo.key (root only), and never sent to us. A recovery key, shown to you once when the repository is created, opens the same repository. We hold neither: we only keep a short check code that tells which recovery key belongs to which server and can’t open anything.
• Your server talks to the platform and to the storage over TLS (HTTPS) only. The storage disks are also encrypted at rest; that protects against a lost or replaced disk, not against someone on the running storage server.
• We can’t read or decrypt your backups: restores are decrypted on your server, never on ours. If you lose both the server (with its repo.key) and the recovery key, nobody can read them.

Append-only storage

• Backups are stored in France, one repository per server, each with its own login limited to that repository.
• Day to day, a server can add backups and read them back, not delete or overwrite them.
• Old backups are pruned at most once a week, right after a backup, with a separate login valid for one hour and limited to that server’s repository. The platform issues that login at most once per server per week.
• You can pause pruning for a server (server page › Retention). No login that can delete is then issued for it, and its storage only grows. Details: storage, retention and pruning.

Known limits

• Root on your server. Anyone with root on your server can read its backups (with repo.key), and can use that server’s keys to get the weekly pruning login and delete that server’s backups. They can also add fake backups: the next pruning counts them in the retention, so real older backups can be removed. Pausing pruning closes both. Your other servers are not affected: each one has its own keys and repository.
• Our platform. The platform can delete a server’s repository: that is how deletion works when you delete a server or your account, or after a cancellation or an unpaid subscription (when backups are deleted). It also sends the retention each pruning uses. Someone who took control of our platform could therefore delete backups, but still not read them.
• One copy. Your backups are stored once, on one storage server, on disks in RAID 6: that survives two failed disks, not the loss of the whole server. Your own server still holds the original data.

Where keys and data live

The agent and the install

• The install script checks the SHA-256 fingerprint of the agent before installing it. The fingerprint comes from our site, like the agent, so it catches a damaged download, not a compromise of our site.
• Agent updates are signed (Ed25519) and the agent refuses an update whose signature doesn’t check out. The signing key is not on the platform.
• The agent downloads restic (version 0.18.1) from restic’s official releases and checks its SHA-256 fingerprint, built into the agent, before using it.
• The agent is one static binary and runs as root (it has to read what it backs up). Apart from that restic download, it only talks to the platform and the storage.
• It never restores over your files without an explicit confirmation (typing the word, or --yes).

On the platform

• Only administrators can open the back office, and they need a second factor. Every back-office page viewed and every action is recorded in an audit log. The back office gives no access to backup content.
• You can protect your own account with a second factor or a passkey. Deleting a server or removing a team member asks for your password again.
• Rate limits protect logins and the API against repeated attempts.
• The platform database is backed up, encrypted, to a second site in Finland.

What we don’t claim

We hold no security certification and publish no availability figure. If that changes, this page will say so, with the certificate.

Report a vulnerability

Write to TODO_LEGAL(EMAIL_SECURITE), in English, French or Spanish. Machine-readable contact: security.txt. This section is our disclosure policy.

What to send

• What you found and where: the page or address, or the agent and the command involved.
• The steps to reproduce, and what an attacker could do with it.
• Whether you want to be credited, and under which name.

Please don’t put another customer’s data in your report. If you came across any, tell us what it was, without copying it.

What we do

• We acknowledge your report within 3 working days, and give you a first assessment within 10 working days.
• We keep you informed until it is fixed, and tell you when the fix is live.
• We aim to fix serious issues within 30 days. If it takes longer, we tell you why and when.
• If you wish, we thank you by name on this page once the fix is out. We pay no reward: there is no bug bounty.

Disclosure

Please give us a reasonable time to fix before any disclosure: we suggest 90 days from your report, or less once the fix is live and our customers have had time to update the agent. We agree on the date with you, and we may publish an advisory of our own.

Scope

• In scope: this site and the client area, the documentation site, the install script, the agent, and the storage service your servers send their backups to.
• Out of scope: services run by other companies (our hosting provider, our payment provider, our e-mail providers): report to them; restic itself: report to the restic project; reports that only list missing headers or e-mail settings without a way to exploit them.

Rules

• Test only with your own account and your own servers.
• Don’t access, change or delete other customers’ data or backups. If you reach any, stop and tell us.
• Don’t degrade the service: no load or denial-of-service tests, no spam, no automated scans that flood the site.
• No social engineering of our staff or customers, and no physical tests.
• Keep the details to yourself until the agreed date.

Within those limits, good-faith research is welcome and we won’t take action against it. TODO_LEGAL(safe-harbour wording for security research to be validated)