How does Secreta protect your passwords?

Secreta encrypts every credential using AES-256-GCM, an authenticated encryption algorithm standardized in FIPS 197 and recommended by NIST SP 800-38D. AES-256-GCM combines a 256-bit key with a unique 96-bit initialization vector (IV) for each encryption operation, producing ciphertext and a 128-bit authentication tag. The authentication tag guarantees both confidentiality and integrity: if even a single bit of the ciphertext is altered, decryption fails. Each encryption call in Secreta generates a fresh IV using the Web Crypto API's cryptographically secure random number generator, eliminating IV reuse risks.

The Web Crypto API is the engine behind all cryptographic operations. It runs natively in the browser, exposing hardware-accelerated AES instructions where available. Secreta never implements its own cipher code or uses third-party JavaScript cryptography libraries. By relying on the browser's built-in implementation, we inherit the security review and hardening performed by browser vendors. The API enforces key isolation: private keys marked as non-extractable cannot be read by JavaScript, reducing the attack surface from memory-scraping exploits.

Every vault in Secreta has its own AES-256-GCM key. Credentials inside a vault are encrypted individually, each with a distinct IV, so compromising one ciphertext reveals nothing about another. The vault key itself is never stored in plaintext on the server. Instead, it is wrapped (encrypted) with the user's master key before transmission. This layered approach means that even if an attacker obtains the database, they face multiple layers of AES-256-GCM encryption with no plaintext keys available.

Zero-knowledge means the Secreta server never receives, processes, or stores your master password or any plaintext credential. Encryption and decryption happen exclusively inside your browser using the Web Crypto API. When you save a credential, Secreta encrypts it locally and transmits only the resulting ciphertext to the server. When you read a credential, the server returns ciphertext and your browser decrypts it. At no point does plaintext leave the browser context.

The server stores your email address, encrypted master key blob, encrypted vault keys, and encrypted credential payloads. It also stores a PBKDF2 salt for key derivation and authentication session tokens. It does not store your master password, any derived key, any vault key in unwrapped form, or any credential field in plaintext. If our database were copied in its entirety, an attacker would obtain only encrypted blobs that are computationally infeasible to decrypt without your master password.

This design has a deliberate trade-off: we cannot recover your data if you lose your master password. There is no backdoor, no server-side decryption capability, and no reset mechanism that bypasses encryption. We provide an Emergency Kit at registration that you should store securely, but ultimately the responsibility for remembering your master password rests with you. This is the cost of genuine zero-knowledge security.

Secreta uses PBKDF2-HMAC-SHA-256 with 100,000 iterations to derive a 256-bit AES key from your master password, following guidance in NIST SP 800-132. A 128-bit cryptographically random salt is generated at account creation and stored alongside your account record. The high iteration count forces an attacker who obtains the salt and encrypted master key to spend significant computational resources per guess, making offline brute-force attacks impractical for strong passwords.

The derived key's sole purpose is to unwrap (decrypt) your master key. The master key is a separate AES-256-GCM key generated randomly at account creation. It is immediately wrapped using AES-GCM with the derived key, and only the wrapped version is sent to the server. When you log in, your browser re-derives the key from your password and salt, then uses it to unwrap the master key in memory. The derived key is never stored, transmitted, or persisted to disk.

This two-layer design means changing your master password only requires re-wrapping the existing master key with a new derived key. Your vault keys and encrypted credentials remain untouched. It also means the derived key is ephemeral: it exists in browser memory only during the login flow, narrowing the window of exposure.

Secreta organizes keys into a strict hierarchy. Each level wraps the level below it, so compromising any single key does not expose the entire system. The chain from your master password down to an individual credential follows five steps:

Each vault key is generated independently when a vault is created, using the Web Crypto API's generateKey function with 256-bit length. The vault key is then wrapped with the user's master key and stored server-side. When a vault is opened, the browser unwraps the vault key, then uses it to decrypt each credential. Because every vault has a unique key, revoking access to a shared vault only requires re-wrapping that vault's key, without affecting other vaults.

Vault sharing uses RSA-OAEP with a 4096-bit key pair and SHA-256 hashing. Each user generates an RSA key pair at account creation. The public key is stored in plaintext on the server. The private key is encrypted with the user's AES-256-GCM master key before being stored, so the server cannot use it.

When you share a vault, Secreta exports the vault's AES-256-GCM key as raw bytes, then encrypts those 32 bytes with the recipient's RSA-OAEP public key. The resulting ciphertext is stored as a vault share record. When the recipient opens the shared vault, their browser decrypts the vault key using their RSA private key (which was first unwrapped with their own master key), then uses the vault key to decrypt credentials normally.

This hybrid approach combines the efficiency of symmetric encryption for bulk data with the key-exchange capability of asymmetric encryption. The vault key never appears in plaintext on the server at any point in the sharing flow. Revoking a share deletes the encrypted vault key record; the recipient can no longer decrypt the vault because they no longer possess the wrapped key.

Secreta's architecture is designed to protect your credentials against specific, well-defined threat categories. Understanding what the system defends against helps you make informed decisions about the risks you accept.

Secreta protects against:

• Server database breach: All credential data is AES-256-GCM encrypted. An attacker who copies the entire database obtains only ciphertext with no plaintext keys available. Brute-forcing 100,000-iteration PBKDF2 is computationally expensive per password guess.
• Man-in-the-middle interception: All traffic between your browser and Secreta servers is encrypted with TLS. Even if TLS were somehow bypassed, the attacker would capture only ciphertext because encryption happens before transmission.
• Insider threat from server operators: The zero-knowledge design means Secreta staff, hosting providers, and infrastructure partners cannot decrypt your data. There is no server-side key, no admin decryption tool, and no backdoor.
• Database leak via SQL injection or misconfiguration: Even if an attacker exploits a vulnerability to read the database, every sensitive field is encrypted. Metadata like email addresses is exposed, but credential content is not.
• Replay attacks on encryption: Each encryption operation uses a unique 96-bit IV generated by a cryptographically secure random number generator. AES-GCM authentication tags detect any ciphertext tampering.

No security tool eliminates all risk. Secreta is transparent about the boundaries of its protection so you can layer additional defenses where needed. The following scenarios fall outside Secreta's threat model:

• Keyloggers or screen recorders on your device: If malware captures keystrokes as you type your master password, or records your screen while credentials are displayed, Secreta cannot prevent that. Use reputable antivirus software and keep your operating system updated.
• Master password compromise: If someone learns your master password through social engineering, shoulder surfing, or finding your written copy, they can decrypt your data. Enable two-factor authentication (TOTP) to add a second layer of defense.
• Unrestricted local device access: If an attacker has physical access to your unlocked device while Secreta is open, they can view decrypted credentials in the browser. Lock your device when stepping away and use short session timeouts.
• Malicious browser extensions: A browser extension with sufficient permissions can read page content, including decrypted credentials displayed in the DOM. Install extensions only from trusted sources and review their permissions.
• Social engineering and phishing: If you are tricked into entering your master password on a fake login page, the attacker obtains your credentials. Always verify you are on the legitimate Secreta domain before entering your password.

We recommend combining Secreta with strong device security practices: full-disk encryption, biometric screen locks, two-factor authentication, and regular software updates. Security is a system, not a single tool.

Secreta's source code is publicly available for audit. Any developer, cryptographer, or security researcher can inspect the encryption implementation, verify key derivation parameters, and confirm that no data leaves the browser unencrypted. Open-source availability eliminates the need to trust our claims on faith: the code is the proof.

Proprietary password managers ask you to trust that their encryption works as advertised. You cannot verify their key derivation iteration counts, confirm that plaintext never reaches their servers, or check for hidden telemetry. With Secreta, every cryptographic operation is traceable in the source. The Web Crypto API calls, the PBKDF2 parameters, the AES-GCM IV generation, the key wrapping flow: all are visible and auditable.

Open source also enables community-driven security improvements. If a researcher identifies a weakness in our implementation, they can report it through our responsible disclosure process and verify the fix themselves. This feedback loop produces stronger security outcomes than closed development cycles that rely on internal review alone.

If you discover a security vulnerability in Secreta, we encourage responsible disclosure. Please report it to [email protected] with sufficient detail for us to reproduce and assess the issue. We ask that you follow these guidelines:

• Do not publicly disclose the vulnerability until we have released a fix and had reasonable time to notify affected users.
• Do not access, modify, or delete data belonging to other users during your research.
• Do not perform denial-of-service attacks or actions that degrade the service for other users.
• Provide a clear description of the vulnerability, including steps to reproduce, affected components, and potential impact.
• Include your contact information so we can coordinate the disclosure timeline with you.

We commit to acknowledging valid reports within 72 hours, providing a timeline for remediation, and crediting researchers who follow responsible disclosure practices (with their permission). We do not pursue legal action against researchers who act in good faith. Contact us at [email protected].