Data Processing Policy

This policy describes how Lock Down Keys processes data from a technical and operational perspective. It is intended for users and legal review. Technical details have been verified by engineering.

1. Where processing runs (browser vs server)

We distinguish between public tools and authenticated vault operations:

Password generation (public demo): Runs in your browser. Generated passwords are never sent to our servers.
Password strength check (public demo): Runs entirely in your browser. The password you enter is never sent to our servers; strength is computed locally and not stored or logged.
Account authentication: Your account password is sent over TLS and verified server-side against a stored hash only. We never store your account password in plain text (see section 2).
Vault (saved passwords): Create, read, update, and delete operations are performed on our servers. Data is encrypted at rest; decryption uses server-held keys that are not exposed to the client.

2. Policy: we do not store your passwords in plain text

We commit to the following, verified by our implementation:

Account passwords: We store only a one-way cryptographic hash (bcrypt). We cannot recover or display your account password. It is never stored in plain text or in a reversible form.
Vault entries (saved passwords): Stored only in encrypted form (AES-256-GCM). We do not store or transmit plain-text vault passwords. Decryption happens server-side for authorized requests only.
Strength-check input (public demo): The password you type never leaves your device. It is used only in the browser to compute the strength result and is not sent to our servers, persisted, or written to logs.

3. Encryption

We use the following encryption measures:

In transit: All traffic between your device and our servers uses TLS (HTTPS).
At rest (vault data): AES-256-GCM. A dedicated master key is used for encryption; it is itself protected and stored in encrypted form. Master keys are rotated on a 90-day interval; previous keys are retained only as needed to decrypt older data.
Account passwords: Stored as bcrypt hashes only; hashing is one-way and not reversible.

4. Audits

We maintain audit trails for security-relevant actions:

Logged events include: authentication attempts (success and failure), access to vault resources, creation and modification of sensitive data, and administrative actions where applicable.
What we do not log: Password values, vault secrets, or any sensitive content. Audit entries contain identifiers, timestamps, resource types, and action types—not secrets.
Retention: Audit logs are retained for a defined period (currently 90 days) and then removed. Exact retention may be updated for compliance; the current value is reflected in our operational documentation.

5. Legal and contact

This data processing policy is intended to complement our Privacy Policy and Terms of Service. For legal or data protection inquiries, contact: info@lockdownkeys.com.

Last updated: February 2025. Technical content verified by engineering.

1. Where processing runs (browser vs server)

We distinguish between public tools and authenticated vault operations:

Password generation (public demo): Runs in your browser. Generated passwords are never sent to our servers.

Password strength check (public demo): Runs entirely in your browser. The password you enter is never sent to our servers; strength is computed locally and not stored or logged.

Account authentication: Your account password is sent over TLS and verified server-side against a stored hash only. We never store your account password in plain text (see section 2).

Vault (saved passwords): Create, read, update, and delete operations are performed on our servers. Data is encrypted at rest; decryption uses server-held keys that are not exposed to the client.

2. Policy: we do not store your passwords in plain text

We commit to the following, verified by our implementation:

Account passwords: We store only a one-way cryptographic hash (bcrypt). We cannot recover or display your account password. It is never stored in plain text or in a reversible form.

Vault entries (saved passwords): Stored only in encrypted form (AES-256-GCM). We do not store or transmit plain-text vault passwords. Decryption happens server-side for authorized requests only.

Strength-check input (public demo): The password you type never leaves your device. It is used only in the browser to compute the strength result and is not sent to our servers, persisted, or written to logs.

3. Encryption

We use the following encryption measures:

In transit: All traffic between your device and our servers uses TLS (HTTPS).

At rest (vault data): AES-256-GCM. A dedicated master key is used for encryption; it is itself protected and stored in encrypted form. Master keys are rotated on a 90-day interval; previous keys are retained only as needed to decrypt older data.

Account passwords: Stored as bcrypt hashes only; hashing is one-way and not reversible.

4. Audits

We maintain audit trails for security-relevant actions:

Logged events include: authentication attempts (success and failure), access to vault resources, creation and modification of sensitive data, and administrative actions where applicable.

What we do not log: Password values, vault secrets, or any sensitive content. Audit entries contain identifiers, timestamps, resource types, and action types—not secrets.

Retention: Audit logs are retained for a defined period (currently 90 days) and then removed. Exact retention may be updated for compliance; the current value is reflected in our operational documentation.