Security and Account

Standard Red Notes combines client-side encryption with server-side identity, authorization, abuse prevention, and availability controls. These layers solve different problems.

Trust boundary

The account password participates in deriving client encryption keys. Normal note and item contents are encrypted before sync and decrypted by clients. The server still necessarily handles operational metadata such as account identity, sessions, timestamps, encrypted payload sizes, IP-derived security events, and authorization records.

Some optional features intentionally widen the data path:

• A hosted AI provider receives the prompt and note/tool content supplied to that request.
• Public share recipients receive the content made available through the link.
• Server OCR receives the file pages configured for extraction.
• Email and Nextcloud backup delivery sends encrypted backup artifacts to those external systems.
• Plaintext desktop backups store readable content outside the encrypted account.

Enable those features only when their additional trust boundary is acceptable.

Authentication controls

Use a dedicated app password or MCP token to avoid placing interactive MFA material in automation. A full MCP token is still a high-impact decrypting credential, not a less-sensitive substitute for the account password. For access to only a subset of notes, use a dedicated automation account; the current bridge does not enforce selected-tag scope.

Recovery

There is no conventional administrator-readable password reset that can simply decrypt an account. Standard Red Notes instead ships an optional, off-by-default recovery flow whose cryptographic work remains in the client.

flowchart TD
  A[Signed-in user enables recovery] --> B[Client creates a separate secret]
  B --> C[Client encrypts a bounded root-key record]
  C --> D[Server stores ciphertext escrow only]
  C --> E[User stores the one-time recovery code separately]
  E --> F{Password later lost?}
  F -->|No| G[Replace after exposure or re-enable after a password change]
  F -->|Yes| H[Signed-out client fetches escrow by opaque locator]
  H --> I[Client decrypts the root key locally]
  I --> J[Client rotates password, sessions, and escrow]
  J --> K[Old code is invalid; save the replacement code]
  H -->|Escrow unavailable or code invalid| L[Stop and use an independent backup]

What must happen before password loss

While signed in, open Preferences -> Security -> Account recovery, enter the current password, and enable recovery. The client:

1. validates the current password and obtains the active root key locally;
2. generates a separate high-entropy recovery secret;
3. encrypts a bounded root-key recovery record with that secret;
4. uploads only the versioned ciphertext escrow; and
5. shows one recovery code containing the account locator and secret exactly once.

Store that code in a protected password manager or offline recovery package, separate from the Standard Red Notes account and the only backup. The recovery secret and wrapping key are never sent to the server.

Logged-out recovery and credential rotation

From the signed-out screen, choose Recover account with an account recovery code. On a trusted computer, enter the complete code and a strong new password twice. The client uses the code’s high-entropy UUID locator to retrieve only the bounded v2 ciphertext escrow, decrypts it locally, signs in with the recovered root key, and changes the credentials through the normal authenticated, compare-and-swap rotation path.

Successful credential rotation invalidates the old escrow and signs out other sessions under the normal password-change contract; the newly issued recovery session remains active. The client then creates a fresh escrow and displays a replacement recovery code. If sign-in succeeds but rotation or re-enrollment fails, the UI reports that partial outcome instead of claiming complete recovery; finish the password change or enable recovery again from Security preferences.

Recovery boundaries

• Recovery must be enabled before password loss. The server does not create an escrow automatically.
• A high-entropy UUID locator reduces account enumeration, but secrecy comes from the recovery secret in the full code.
• The server returns generic unavailable responses for absent, malformed, or legacy escrow; older escrow can be deleted but not used by this flow.
• Changing the account password invalidates the current escrow. Opt in again afterward only if you still accept the tradeoff.
• Replacing a code immediately invalidates the previous code. Disabling recovery deletes the server-side escrow and invalidates every issued code.
• Recovery is not a backup: it does not preserve deleted items, unsynced local changes, attachments outside the backup set, or an unavailable server.

A resilient safety net therefore includes:

1. a saved 2FA recovery code;
2. a known account password;
3. if opted in, the separate account-recovery code;
4. at least one current encrypted export; and
5. verified access to the backup’s password or other decryption material.

An administrator can reset a user’s server-side MFA state. That operation does not recover the account encryption password.

Recovery-code handling

• Label MFA recovery material and account-recovery material distinctly; they solve different problems.
• Display and copy either recovery code only in a private environment.
• Store it outside the Standard Red Notes account it protects.
• Prefer an offline password manager record or sealed recovery package.
• Replace account-recovery material immediately if it may have been exposed; rotate MFA recovery material through the appropriate MFA control.
• Test the documented recovery path before depending on it.

Protected notes and local locks

Protected-item access and app locks reduce accidental local disclosure. They do not change what a deliberately unlocked client can decrypt, and they do not prevent screen capture, clipboard capture, malware, or an authorized recipient from copying content.

On supported web and desktop clients, the local passkey gate is an additional app-lock factor. It can be registered only while an app passcode exists. If the platform passkey later becomes unavailable, verify the app passcode and choose the passcode fallback to disable that local passkey credential. Removing the app passcode also disables and removes the passkey gate.

On mobile, biometric/keychain integrations and privacy-snapshot or secure-window controls add platform protection. On desktop, OS keychain security and the machine’s account security remain part of the boundary.

Public sharing and collaboration

Shared vaults preserve an authenticated membership and permission model. Public links do not: possession of the link is the access mechanism. A burn-after-reading link reduces repeated retrieval but cannot revoke a copy already made by the first reader.

Before sharing:

• verify the exact note and attachment set;
• choose the narrowest vault permission;
• set expiry or burn behavior where available;
• transmit links through an appropriate channel; and
• revoke links and memberships that are no longer needed.

Server-side security

Operators can use the Admin Security tab or srn-admin for:

• rate-limit tiers and adaptive escalation;
• IP block and allow lists;
• account lockout review and unlock;
• permanent, temporary, and shadow bans;
• reversible suspension;
• registration policy and approval;
• role/group/effective-permission review; and
• audit-log inspection.

Administrative actions are server-authorized. Hiding an admin control in the web client is not sufficient authorization.

Secrets and configuration

• Keep .env, server-settings overlays, app passwords, backup credentials, provider API keys, and MCP HTTP bearer tokens out of version control.
• Use long independent random values for JWT, valet, database, and shared-gate secrets.
• Terminate TLS at a trusted reverse proxy and preserve the real client IP only through explicitly trusted proxy hops.
• Do not expose database, Redis, internal service ports, or the Docker socket to untrusted networks. Put n8n on its own TLS hostname with its own login; never route it through the Standard Red Notes origin.
• Review audit logs after changes to users, roles, registration, security lists, feature gates, and service lifecycle.

For operator controls, continue with Administration. For credential use in automation, see MCP Bridge and Workflows with n8n.