Security

Cardinal is security infrastructure, so the useful thing a page like this can do is be specific about limits.

Not audited

Nobody outside the project has reviewed the cryptography, the session handling or the policy evaluation. That is listed as a requirement before 1.0 and it has not happened. Treat the code as unreviewed, because it is.

What the design commits to

• No passwords. Nobody signs in with one, and no account has one; the only stored secret of that kind is the mail relay's, sealed at rest. Passkeys are the credential, and administrative actions additionally require a device-bound key used within the administrative window, fifteen minutes unless configured.
• Default-deny. Cedar grants nothing implicitly, a forbid always beats a permit, and a rule naming a group that does not exist grants nothing.
• Secrets are not stored in the clear. Session tokens, recovery codes and access tokens are stored as hashes; the token-signing key and both certificate authority keys are sealed with encryption keys that live in configuration rather than the database, and Cardinal refuses to start if two of them are equal.
• The audit journal is append-only and hash-chained, and a state change and its journal entry commit in the same transaction. Personal data never enters the journal, so erasure never has to break the chain.
• Erasure removes access. A GDPR Article 17 erasure deletes the account's credentials and disables it, not only its personal columns.

Reporting something

Report privately, not as a public issue: SECURITY.md in the repository has the current contact and disclosure policy.