The diagram below shows how a user's password becomes ciphertext. The server sees the password exactly once (at login, in memory) — it is never written to disk or logs, and is discarded after KEK derivation.

  Password (user-supplied)                user-specific 32-byte salt
      │                                            │
      └──────────────┬─────────────────────────────┘
                     ▼
          ┌──────────────────────────┐
          │       Argon2id KDF       │   m=64 MiB (65536 KiB)
          │      (RFC 9106, type=id) │   t=3 iterations
          │                          │   p=4 lanes
          └──────────────┬───────────┘   hash_len=32 bytes
                         ▼
                KEK (32 bytes, raw)
                         │
                         ▼
          ┌──────────────────────────┐
          │ AES-256-GCM unwrap(UDK)  │   AAD = "2at:v3:keywrap:<user_id>:udk"
          │   wrapped blob (61 B):   │   nonce = 12 bytes (CSPRNG, per-wrap)
          │   0x03 ‖ nonce ‖ ct+tag  │   tag   = 16 bytes
          └──────────────┬───────────┘
                         ▼
                UDK (32 bytes, random, per-user)
                         │
                         ▼
          ┌──────────────────────────┐
          │ AES-256-GCM encrypt()    │   AAD = "2at:v3:field:<table>:<col>:<user_id>"
          │                          │   nonce = 12 bytes (CSPRNG, per-record)
          │                          │   tag   = 16 bytes
          └──────────────┬───────────┘
                         ▼
       "v3:" ‖ base64url( nonce ‖ ciphertext ‖ tag )
                         │
                         ▼
                    PostgreSQL row

Notable properties:

• Password never touches disk. Only the KEK-wrapped UDK is persisted.
• Password change = instant. Only the 61-byte wrapped UDK is re-written; user data is untouched.
• UDK lives only in the authenticated session (Valkey, TLS, at-rest encrypted) and is flushed on logout.
• Recovery key path: HKDF-SHA256("2at-recovery-kek") derives an alternate KEK that also wraps the UDK, giving users a password-reset escape hatch without operator involvement.

Argon2id (KDF)

Chosen over PBKDF2, bcrypt, and scrypt because it is the only memory-hard KDF standardized by the IETF (RFC 9106) and recommended by OWASP 2024. Memory hardness makes GPU/FPGA/ASIC attack hardware economically unviable: an attacker must spend on RAM, not just on ALUs. The id variant hybridizes data-independent and data-dependent addressing to resist both side-channel and time-memory trade-off attacks.
Competitor context: tools using raw PBKDF2 are roughly 1000× cheaper to brute-force per candidate password at current GPU prices.

AES-256-GCM (AEAD)

Authenticated Encryption with Associated Data per NIST SP 800-38D. Provides both confidentiality and integrity in a single pass; tampering with any byte of ciphertext or AAD causes decryption to fail with an InvalidTag exception — no silent corruption. Chosen over AES-CBC (malleable, padding-oracle prone) and raw ChaCha20 (no AEAD) because it runs on AES-NI hardware with multi-GB/s throughput on every production CPU we deploy to (Graviton3 / x86-64).

12-byte random nonces

Generated fresh per encryption via os.urandom(12) (CSPRNG). NIST SP 800-38D §8.2.2 explicitly permits random 96-bit nonces. Birthday bound collision probability remains below 2⁻³² until ~2³² encryptions under the same key — far beyond any realistic user data volume.

AAD v3 format

Every field-level ciphertext is bound to its (table, column, user_id) context via AAD: 2at:v3:field:<table>:<column>:<user_id>. This prevents a class of attacks where a DB-level attacker copies ciphertext from column A into column B (say, pasting a suppressor serial into a firearm row) in the hope that the server will decrypt it in a different UI context. With AAD binding, such a swap produces an InvalidTag on read. Key-wrap operations use an analogous scheme: 2at:v3:keywrap:<user_id>:<purpose>.

HKDF-SHA256 (recovery key)

Recovery keys carry 192 bits of entropy (secrets.token_bytes(24)) and are printed once at signup. HKDF provides domain-separated KEK derivation (info=b"2at-recovery-kek") per RFC 5869. The recovery KEK independently wraps the UDK, so losing a password does not lose data; losing both password and recovery key means the data is cryptographically unrecoverable by design.

We explicitly enumerate what the design defends against and what it does not. Truth-in-marketing matters here.

In-scope (defended against)

• Full database compromise (stolen dump, rogue DBA, SQL injection read) — encrypted fields are ciphertext only; no plaintext serial/make/model/caliber exists in the database.
• Stolen RDS snapshots / S3 backups — backups are GPG AES-256 encrypted; RDS is encrypted at rest with AWS KMS.
• Compromised application server (read-only) — the server does not persist KEKs or UDKs. A memory dump during an active session exposes only the currently logged-in users' UDKs, not other users'.
• Field-swap / row-swap attacks — AAD binding causes GCM tag verification to fail if ciphertext is moved between fields, rows, or users.
• MITM on the wire — TLS 1.2/1.3 at the ALB, HSTS with preload, secure cookies.
• Offline password cracking of the KEK-wrap — Argon2id with m=64 MiB makes distributed brute-force expensive enough that even weak but non-trivial passwords remain safe for realistic attacker budgets.
• Weak password reuse (credential stuffing) — HIBP breach check at signup rejects known-pwned passwords.

Out of scope (NOT defended against)

• Compromised user browser or endpoint (malware, keylogger, malicious extension) — if the attacker controls the user's machine, they see plaintext as the user does. No server-side cryptography can fix this.
• Compromised application server (active RCE) — an attacker with code execution can log passwords as users authenticate going forward. Already-stolen database rows remain protected, but a live RCE is effectively "over the shoulder."
• Physical device theft after the user has unlocked — an unlocked, logged-in session exposes decrypted data. Session expiry and re-auth for sensitive actions mitigate but do not eliminate this.
• User reuses a weak password across sites and it appears in a breach corpus with our email — MFA reduces blast radius; HIBP check helps at signup.
• User loses both password AND recovery key — data is cryptographically lost. This is a design trade-off, not a bug.
• Legal compulsion to modify the application to exfiltrate user input — a hostile code push could log passwords before key derivation. We mitigate with signed releases, audit logs, and our public source commitment, but we cannot cryptographically prevent future-you from shipping bad code.

We are not a nation-state target. Our design makes a database breach a non-event for encrypted fields, and raises the cost of attacks that require controlling the runtime. It does not claim magic.

All values below are constants in app/utils/crypto.py.

Every field marked ENC uses encrypted_string_property or encrypted_float_property with the user's UDK and the AAD format shown above. Fields marked plain are left queryable (indexes, sorting, counts, date ranges) and are not considered sensitive on their own.

Structural enums (platform, type, status) are stored as opaque integer codes via _obfuscated_property. A raw database dump shows platform=4, status=1, not "glock" or "active".

We welcome security research. Please report vulnerabilities privately so we can fix and coordinate disclosure.

Contact

security@2atracker.com

PGP key

Available on request from the contact address above. Publishing a stable long-lived PGP key is on our roadmap.

Scope

*.2atracker.com production, the open-source application code, and the Terraform infrastructure in infra/aws/. Out of scope: social engineering of staff, physical attacks, DoS/volumetric tests, and third-party services (Stripe, AWS, Umami, CDN).

Safe harbor

Good-faith research that complies with this policy will not be pursued legally. Please avoid accessing, modifying, or exfiltrating other users' data; use only accounts you own or have permission to test.

Bounty

We do not currently run a paid bounty program. We offer public credit, written thanks, and (for significant findings) swag and free Pro-tier accounts. This will evolve as the company grows.

SLA

Acknowledgement within 72 hours. Triage within 7 days. Fix timeline proportional to severity.

If you believe you've found an active compromise of user data, please mark your message URGENT in the subject line.

The claims on this page are mechanical consequences of a single file. Read it:

• app/utils/crypto.py — every KDF, cipher, nonce, and AAD constant
• app/models.py — every use of encrypted_string_property / encrypted_float_property
• app/auth/routes.py — login, KEK derivation, UDK unwrap, session storage
• tests/test_crypto*.py — round-trip tests, AAD-swap tests, version-migration tests

Quick grep to verify:

# confirm Argon2id parameters
grep -E "ARGON2_(TIME|MEMORY|PARALLELISM|HASH)_" app/utils/crypto.py

# confirm 12-byte GCM nonce
grep "os.urandom(12)" app/utils/crypto.py

# confirm AAD format
grep "2at:v3:" app/utils/crypto.py

# list every encrypted field
grep -E "encrypted_(string|float)_property" app/models.py

If you find a discrepancy between the code and this page, that's a bug. Please report it via the disclosure channel above.