Appearance
Security & encryption
AuroraDocs combines local-first storage, AuroraCloud account security, role-based workspace access, and optional per-workspace end-to-end encryption.
End-To-End Encryption
E2EE is enabled per workspace from Settings → Data and encryption. When enabled, supported workspace content is encrypted on the device before it is synced. AuroraCloud stores encrypted payloads and encrypted key material, not readable workspace content.
Unlock is independent of your login password. Changing, resetting, or replacing your password — including switching to OAuth sign-in — never affects encrypted content. Your account key (which wraps every workspace key) is protected by one or more recovery methods, managed from Settings → Encryption.
Recovery & unlock methods
You can hold several recovery methods at once:
- Device — every device you trust stores its own copy of the account key, wrapped by a non-extractable key held only by that device. Once trusted, that device unlocks silently. Device slots are created automatically the first time you unlock on a device, and can be revoked when a device is lost or sold.
- Recovery phrase — a 12-word phrase generated when you enable E2EE. It is the guaranteed fallback for your first device or when every trusted device is gone. AuroraDocs keeps no copy.
- Key file — an optional offline method: AuroraDocs generates a random 256-bit key, offers it as a one-time download, and you store the file somewhere safe. The material is generated on your device and is never sent to the server. Treat it like a password.
WARNING
Keep at least two recovery methods in separate places — for example a written recovery phrase and a key file on an encrypted drive. If you lose every method (all trusted devices, the recovery phrase, and every key file), your encrypted content is permanently unrecoverable by design — AuroraDocs has no copy of these secrets and cannot decrypt for you.
Adding a new device
On a new or untrusted device you can:
- Approve from a trusted device — the new device shows a QR code and a short pairing code; an already-trusted device scans or enters it, and the account key is handed over through an end-to-end-encrypted exchange. The new device then unlocks silently, with no recovery-phrase entry.
- Enter your recovery phrase — the always-available fallback. It also provisions a device slot so future unlocks on that device are silent.
- Use a key file — unlock with a stored key file directly from the lock screen.
Managing recovery methods
The slot manager in Settings → Encryption (visible only when E2EE is enabled and your account is unlocked) lets you:
- Rotate the recovery phrase — generate a new phrase; the old one is invalidated only after the new one is verified, so you never lose access mid-rotation.
- Add a passphrase or key file — extra recovery methods alongside the phrase.
- Remove a slot — revoke a device or an extra method. You cannot remove your last recovery-capable method (phrase or key file); add another one first.
What the server can and cannot do
AuroraCloud stores only encrypted key blobs and the non-secret parameters needed to use them. It never stores your recovery-phrase words, your key-file material, or your device key. An operator with full database access can see that you have slots and when they were last used, but cannot read your content or unlock your account. A transparency panel in Settings → Encryption spells this out for the current workspace.
Key rotation (for example after removing a member, below) is a client-side re-wrap: the server receives a new encrypted blob and discards the old one without ever seeing the plaintext key.
Forward-looking encryption (advanced)
AuroraDocs can wrap keys with a hybrid post-quantum scheme (X25519 + ML-KEM) for protection against future "harvest-now, decrypt-later" attacks. It is off by default while mobile support lands; existing workspaces keep working unchanged.
Locked Workspaces
When an encrypted workspace is locked:
- page content and protected metadata stay unavailable
- readable Markdown/HTML export is blocked
- AuroraAI, server retrieval, and MCP cannot read locked content
- local folder watchers are restricted so encrypted files are not auto-imported or overwritten in the background
Unlocking happens on the device. The unlocked plaintext is available to the app session so you can read, edit, export, or intentionally send selected context to a BYOK provider.
Backups And Exports
AuroraBak backups (.aurorabak and .aurorabak-bundle) preserve encrypted workspace content as encrypted data. They are restore formats, not readable plaintext exports.
Readable exports such as Markdown or HTML are different. Aurora can create them only after the encrypted workspace is unlocked, and it warns because the downloaded files are plaintext outside Aurora's encryption boundary.
Multi-Member E2EE
Encrypted shared workspaces use per-member wrapped workspace keys so collaborators can be granted access without storing plaintext content on the server. Members still need valid workspace membership and an unlock path on their device.
Removed members
Removing a member triggers workspace key rotation: a new key generation is created and re-wrapped only for the remaining members, all new content uses it immediately, and existing content is re-encrypted in the background. A removed member who saved the old key can at most read content that already existed while they were a member.
Authentication
AuroraCloud account security includes:
- bcrypt password hashing
- short-lived access tokens and refresh tokens
- refresh-token replay detection
- strict JWT algorithm handling
- server-side session revocation
- optional authenticator-app TOTP or email OTP when policy allows it
- required MFA for elevated/admin roles
- recent security activity history
- suspicious-login alerts for new device profiles and broad new network areas
OAuth sign-in buttons for Apple, GitHub, Google, or Microsoft can appear when the AuroraCloud API host is configured for them. OAuth sign-in is separate from invite-code signup and encrypted-workspace unlock rules.
Workspace Access
Workspace roles are enforced by AuroraCloud:
| Role | Read | Edit | Manage members | Delete workspace |
|---|---|---|---|---|
| Owner | yes | yes | yes | yes |
| Editor | yes | yes | no | no |
| Viewer | yes | no | no | no |
Direct object shares, guest links, and published pages have their own access rules. Password-protected links require the visitor to enter the link password before content is shown.
Desktop Secret Storage
Desktop provider keys and similar device-only secrets are session-only unless you explicitly enable secure storage. When secure storage is enabled, Aurora stores them in the OS keychain: Keychain Access on macOS, Credential Manager on Windows, or Secret Service/libsecret on Linux.
Aurora does not silently downgrade desktop secrets into plaintext files if the keychain is unavailable.
Data Residency
AuroraCloud production is hosted on EU infrastructure. Files use private object storage and are delivered through AuroraCloud-controlled access paths.
Reporting A Vulnerability
Email contact@auroradocs.eu with the details. Please avoid public disclosure until there has been time to respond.