Security Model

Account Sharing uses a layered cryptographic model to ensure credentials are encrypted before they leave the client, and that only authorized users can decrypt them. Optserv's servers never receive or store plaintext credentials.

Cryptographic layers

1. Key derivation — PBKDF2 + SHA-256

When a user accesses Account Sharing, their encryption key is derived from a secret using PBKDF2 (Password-Based Key Derivation Function 2) with:

• Hash algorithm: SHA-256
• Iterations: 210,000
• Purpose: Produces a strong symmetric key from user-specific secret material

210,000 iterations aligns with current OWASP recommendations and makes brute-force attacks on the derived key computationally expensive.

2. Payload encryption — AES-GCM 256-bit

Each credential (the actual login, password, or secret) is encrypted using AES-GCM with a 256-bit key.

• Algorithm: AES-GCM (Galois/Counter Mode)
• Key size: 256-bit
• Why AES-GCM: Provides both encryption (confidentiality) and authentication (integrity). A tampered ciphertext will fail to decrypt.

The AES key used to encrypt a specific item is unique per item — not a single company-wide key. This limits the blast radius if a key is ever compromised.

3. Key sharing — RSA-OAEP + SHA-256

For sharing an item with another user, the item's AES key must be securely transferred. Optserv uses RSA-OAEP for this:

• Algorithm: RSA-OAEP (Optimal Asymmetric Encryption Padding)
• Hash: SHA-256
• Process: The item's AES key is wrapped (encrypted) with the recipient's RSA public key. Only the recipient's private key can unwrap it.

This means:

• The sharing process never exposes the plaintext AES key to Optserv's servers
• Each recipient in an item's access list holds an independently encrypted copy of the AES key
• Revoking access means removing the recipient's encrypted key copy — they cannot decrypt the item after that

Why this matters in practice

Optserv can't read your credentials. Because encryption happens client-side, the server only ever sees ciphertext. Even if Optserv's database were compromised, your stored credentials remain encrypted.

Revoking access is cryptographically meaningful. When you remove someone from an item's access list, you remove their copy of the decryption key. Unlike a shared link that stays valid after revocation, this actually prevents decryption.

Offboarding is clean. When an employee is offboarded, their RSA key pair becomes inaccessible. Items they owned can be re-keyed; items they had access to are already inaccessible to their account.

Summary

See also: Sharing & Offboarding, Encryption at Rest and in Transit.