{{ app_name }} | Public threat model

Methodology: STRIDE (Spoofing / Tampering / Repudiation / Information disclosure / Denial of service / Elevation of privilege) applied to five surfaces of the product. Each line: threat, ARDNTECH mitigation, assumed trade-off.

Document intended for CISOs, auditors and security researchers. The AGPL source code is public on github.com/aegirex/server. The detailed operational runbooks remain reserved for design partners under NDA.

1. Modelled actors

The nine attacker profiles taken into account in the model.

Actor	Description	Capabilities
External attacker	Internet, no initial access	Brute force, phishing, web exploits, network MITM
Phished user	User targeted by a clone site	Submits their credentials to an attacker domain
Malicious co-tenant	User of another ARDNTECH organisation	Attempts to read the secrets of neighbouring organisations
Compromised browser	Browser infected by malware or a malicious extension	Access to the DOM, can read input fields
Server administrator	Infrastructure operator with SSH access to the server	Reads the database, reads memory, modifies the code
Database exfiltration	Stolen backup, leaked SQL dump	Complete database snapshot
Judicial authority	Legal requisition, administrative warrant	Compels the host to provide the stored data
ARDNTECH insider	Future employee or contractor of ARDNTECH	Code review, deployment access, log reading
Quantum adversary	Operational quantum computer (horizon > 2030)	Breaks RSA / ECC in polynomial time (Shor)

2. Protected data

Data classification and protection level at rest.

Data	Sensitivity	Storage
User master password	Critical	Argon2id hash only (RFC 9106)
Content of secrets (payload)	Critical	End-to-end encrypted (OpenPGP), the server stores an opaque blob
User OpenPGP private key	Critical	Never on the server. Stored locally, protected by a user passphrase
TOTP secrets at rest	Critical	Encrypted with XChaCha20-Poly1305 (key outside the database)
Webhook secrets at rest	Critical	Encrypted with XChaCha20-Poly1305 (key outside the database)
Secret and folder names	Moderate	In cleartext server-side. Trade-off documented 5.1
Audit log	High	HMAC-SHA-256 chain, tamper-evidence in O(1)

3. Threats and mitigations per surface

3.1 Web SaaS application

Threat	Mitigation	Status
Brute force on the password	Rate limiter 5 attempts / 15 min per IP + Argon2id (256 MiB, 5 passes), 1 s per local attempt	Delivered
Credential stuffing	Same rate limiter + opt-in HIBP scan after login (explicit GDPR consent)	Delivered
2FA bypass	TOTP RFC 6238 with issuer pinning + single-use recovery codes + WebAuthn PRF	Delivered
Stored or reflected XSS	Strict CSP (script-src 'self' 'wasm-unsafe-eval'), Trusted Types enabled, automatic Twig escaping	Delivered
Compromise of the OpenPGP.js dependency	Library vendored with a SHA-256 fingerprint verified at build time (SRI integrity manifest)	Delivered
Phishing of the master password	Strong mitigation upcoming: WebAuthn PRF passkeys, which remove the transmission of the password and are bound to the origin domain by the browser. In the meantime: user training + UI indicators.	Upcoming

3.2 Encrypted storage

Threat	Mitigation	Status
Stolen database dump	E2E OpenPGP encrypted payload unreadable without the user's private key. Passwords as Argon2id hash, non-recoverable	Delivered
Stolen backup	Encrypted backups (Argon2id + ChaCha20-Poly1305), multi-recipient. Automated restoration test in CI	Delivered
Server administrator reads the content of a secret	Impossible without the user's private key. The server stores only opaque blobs	Delivered
Tampering with the audit log	HMAC-SHA-256 chain, detection in O(1) at verification. Chain detail	Delivered

3.3 REST API

Threat	Mitigation	Status
Cross-organisation data leak	Each API token bound to a single organisation. Systematic filtering at every endpoint. Explicit isolation tests in CI on every commit	Delivered
API token theft	Token hashed with Argon2id in the database. Free rotation by the user. Minimal scope (read / write) configurable	Delivered
Application denial of service	Rate limiter per token and per IP (Symfony framework)	Delivered

3.4 Browser extensions

Threat	Mitigation	Status
Compromise of the build pipeline	SHA-256 fingerprint verification of dependencies chained to the build. Signed SBOM planned	Delivered
Closing the popup = temporary loss of access	First-version trade-off: the private key is not persisted to limit the attack surface. Upcoming: configurable auto-lock + persistence via a controlled service worker.	Upcoming
Capture of credentials on a phishing site	The user sees the real domain name in the extension pop-up before clicking « Save »	Delivered

3.5 Self-hosted infrastructure

Threat	Mitigation	Status
Compromised Docker image	Automated vulnerability scan in CI. Sigstore signature planned for user verification at deployment	In progress
Untested backup	Automated restoration test in CI on every release. No untested backup in production	Delivered
mTLS in production	Can be enabled by configuration. Audit (logs only) then enforcement modes available	Delivered

4. Protection perimeter - assumed limits

Editorial honesty: here are the surfaces that {{ app_name }} does not cover alone, and the recommended mitigation.

Limit	Why	Recommended mitigation
Complete compromise of the user's machine	Malware with access to the browser's RAM can read the decrypted private key	Hardware passkey (YubiKey, TPM) that confines the key in a secure element
Compromise of the ARDNTECH server (root)	A root attacker can read the active HTTP sessions	The stored secrets remain unreadable (zero-knowledge). Only the sessions open at the moment of compromise are at risk. A short auto-lock is recommended
Loss of the master password	A direct consequence of strict zero-knowledge: no server-side means of recovering the key	Recovery codes printed at creation. Upcoming: Shamir M-of-N sharing for Enterprise plans
Quantum adversary (horizon > 2030)	OpenPGP v6 + AES-256 are estimated safe for 5 to 10 years according to the ANSSI RGS 2024	Post-quantum migration (ML-KEM, ML-DSA) under long-term assessment
Physical attack on the user's machine	ARDNTECH is a logical vault, not a physical safe	Short vault auto-lock + hardware WebAuthn passkey
ARDNTECH insider (future employee)	An assumed limit of the SaaS publisher trust model	NDA, separation of duties, mandatory code review, tamper-evident audit chain, principle of least privilege

5. Assumed trade-offs

5.1 Secret and folder names in cleartext server-side

Choice: names stored in cleartext server-side.

Why: instant server-side search, display of the tree structure without decryption on every navigation, hierarchical folder sharing possible.

Impact: an attacker who exfiltrates the database sees that a secret named « AWS Prod » exists in the « DevOps / Cloud » folder. They do NOT see the content (E2E encrypted payload).

Alternative considered: an « anonymise me » option that also encrypts the names. Significant UX cost: no server-side search, a full client scan on every request.

5.2 Password in cleartext in the DOM during entry

Choice: OpenPGP encrypts the payload after the user has typed their password.

Why: no alternative, the browser must see the cleartext to allow the user to enter it.

Mitigations: Trusted Types CSP prevents DOM XSS from injecting exfiltrating JavaScript. Upcoming: WebAuthn passkeys that completely remove the transmission of passwords.

5.3 Master password = the vault's only key

Choice: no recovery if the user loses both their master password AND their recovery codes.

Why: strict zero-knowledge. If we could recover it, there would be a decryption path server-side.

Upcoming mitigation: Shamir sharing of the private key (M-of-N shares), one share held by ARDNTECH with procedural safeguards (unlocking only with the presence of N-1 other shares validated by the user). Reserved for Enterprise plans.

6. Incident response plan

Level	Trigger	Action
L1 Suspicion	Anomaly in the audit log, user report	Internal investigation within 24 h, audit chain verification
L2 Confirmed compromise	Technical compromise confirmed by the investigation	User notification within 72 h (GDPR Art. 33), rotation of impacted keys, implementation of mitigations
L3 Major compromise	Database or source code compromised	CNIL and ANSSI notification, public transparency report, external forensic audit

Responsible disclosure: In accordance with RFC 9116, a /.well-known/security.txt file at the root of the website indicates our contact address security@aegirex.eu. Acknowledgement time: 72 h.

Clarify the document?

This threat model is a living document. If you are a CISO, an auditor or a security researcher and a threat is poorly modelled, contact us directly.

Claims/proofs matrix security@aegirex.eu

Public threat model.