Kaynağa Gözat

Updated documentation

Efren Yevale Varela 1 ay önce
ebeveyn
işleme
4ab3f1f588
2 değiştirilmiş dosya ile 3 ekleme ve 28 silme
  1. 3 2
      docs/SECURITY.md
  2. 0 26
      docs/TODO.md

+ 3 - 2
docs/SECURITY.md

@@ -341,10 +341,11 @@ store can be shown untouched.
 | TOTP secrets | AES-256-GCM under HKDF-SHA256 (info `totp-gcm-v2`; pre-migration v1 blobs under bare `SHA256(totp_key)` still decrypt) | Readable only if the TOTP key also leaks. |
 | TOTP recovery codes | Argon2id PHC | Offline cracking only. |
 | DCR registration access tokens | Keyed HMAC (`registration_access_token_hash`) | Opaque while the pepper stays outside the dump. |
-| Emails, client names, contacts, redirect URIs, scopes, entitlements | Plaintext | Full disclosure. |
+| Emails, client names, contacts, redirect URIs, JAR `request_uris`, `jwks_uri`, scopes, entitlements | Plaintext | Full disclosure. |
 | Client public keys (`jwks`) | Plaintext | Public by design. |
 | `tls_client_auth_subject_dn` and certificate thumbprints | Plaintext | Identifier disclosure. |
-| `is_admin`, `disabled`, `must_change_password`, timestamps | Plaintext | Metadata disclosure. |
+| `is_admin`, `disabled`, `must_change_password`, `totp_enabled`, timestamps | Plaintext | Metadata disclosure. |
+| Client registration metadata (`grant_types`, `response_types`, `token_endpoint_auth_method`, `software_id`, `active`, `dpop_bound_access_tokens`, `client_id_issued_at`, `client_secret_expires_at`) and catalog metadata (scope/redirect `description`, `enabled`, `kind`, actor ids `granted_by`/`created_by`/`attached_by`) | Plaintext | Metadata disclosure. |
 
 If the key store leaked too, the dump is a full compromise: TOTP secrets
 decrypt, the Argon2id hashes are the only barrier left on passwords and client

+ 0 - 26
docs/TODO.md

@@ -10,32 +10,6 @@ boundary can reach.
 This document only records the gaps. It does not describe anything that is
 already implemented, and it does not propose code changes here.
 
-## What a database dump exposes today
-
-The baseline is better than a naive server's, because secrets are stored hashed
-or encrypted, and the key material lives outside the database. The table below
-is the full accounting.
-
-| Data | Protection at rest | If the dump leaks |
-| --- | --- | --- |
-| User passwords | Argon2id PHC, salted (`src/db/user_repo.rs`) | Offline cracking only. |
-| Client secrets | Argon2id PHC (`src/db/client_repo.rs`) | Offline cracking only. |
-| TOTP secrets | AES-256-GCM under HKDF-SHA256 (`src/crypto/totp.rs`, info `totp-gcm-v2`; pre-migration v1 blobs under bare `SHA256(totp_key)` still decrypt) | Safe only if the key is not in the dump. |
-| TOTP recovery codes | Argon2id PHC (`src/db/user_repo/totp.rs`) | Offline cracking only. |
-| DCR registration access tokens | Keyed HMAC hash (`src/db/client_repo.rs`) | Safe; the pepper is not in the database. |
-| Emails, client names, contacts, redirect URIs, scopes, entitlements | Plaintext | Full disclosure. |
-| `jwks` (client public keys) | Plaintext | Public by design. |
-| `tls_client_auth_subject_dn` and cert thumbprints | Plaintext | Identifier disclosure. |
-| `is_admin`, `disabled`, `must_change_password`, timestamps | Plaintext | Metadata disclosure. |
-
-The critical dependency is outside the database. The token pepper and the TOTP
-encryption key are supplied through environment variables or mounted files
-(`src/config/raw.rs`, `src/config/build.rs`), never through a table. A pure
-database dump therefore does not yield them, and every hashed or encrypted
-column above stays opaque. This separation is the single most important
-protection the server has today, and the gaps below are mostly about not
-depending on it alone.
-
 ## Gaps to plan and implement
 
 Each item names the risk, the change to plan, and the files it would touch. The