Security

Passwords and authentication

New passwords use Argon2id with explicit memory, time, parallelism, and output settings, a unique library-generated salt, and a required server-side pepper kept outside the database. Recognized legacy bcrypt hashes can be verified and upgraded after successful authentication. Password-reset tokens are time-limited, one-time, and stored only as hashes.

Multi-factor authentication

When enabled for the community and account, sign-in requires a time-based authenticator code after password verification. One-time backup codes are stored as hashes and consumed once. Disabling MFA or regenerating backup codes requires current security confirmation.

Sessions

Sessions use an HttpOnly, SameSite=Lax cookie and secure transport in production. The service stores a hash of the session token, applies both idle and absolute expiration, and invalidates sessions on logout and supported sensitive account changes such as password reset.

Authorization and isolation

An active membership establishes community scope. Roles collect permissions, while every protected server action validates the required permission and target community. Member and administrative workspaces are separated, private member fields require additional authority, and encrypted-chat content remains participant-scoped.

Registration protection and audit

Public registration uses neutral responses, rate limits, optional CAPTCHA verification, protected invitation links, duplicate-safe application handling, cooldown-controlled email notices, and audited decisions. Audit metadata is sanitized to exclude common secret fields and is stored in the application database rather than an immutable external log.

Encrypted-chat boundary

Chat message and attachment content is encrypted in participant browsers, while the service retains ciphertext and necessary metadata. Private keys and recovery passwords are user-held. This does not remove endpoint, recipient, metadata, key-loss, or recovery risks. The Encrypted chat guide is the authoritative user guide for backup, restore, devices, revocation, attachments, participant changes, and E2EE limitations.

Operator responsibilities

• Protect first-run initialization before public exposure and use strong, unique setup, session, password-pepper, database, email, and encryption secrets.
• Use HTTPS, a correct public origin, secure cookies, least-privilege roles, current software, and restricted administrative access.
• Back up the database, uploaded files, and configuration securely, and test restoration. Server backups do not replace each member’s encrypted-chat key backup.
• Review audit and delivery failures, rotate compromised secrets through supported procedures, and never print credentials, cookies, tokens, private keys, or recovery material.