Platform

Platform overview How it works Authorization testing Evidence & reports Private scanning Integrations

Solutions

Security agencies Product teams Regulated industries Partner programme

Learn

Blog Knowledge hub Compare

Resources

Pricing Documentation Help centre FAQ Security & data What we haven’t proved

Company

About Contact Careers Sign in to the platform Start a $199 pilot →

Home / Help centre / Security & privacy

Security & privacy

How does Cyberlop store my credentials and tokens?

Quick answer

The app stores credentials with AES-256-GCM encryption on a storage volume that is also encrypted at rest. After you save a secret, the app never shows it again. Passwords and session tokens use hashes instead, and logs redact tokens and cookies.

The short version

Every secret you give the app is encrypted before storage, and the app never shows it again. That covers AI provider keys, Git tokens, single sign-on and vault secrets, and target login credentials. The storage volume itself is encrypted too.

WhatHow it is protected
AI provider key or token, Git tokenEncrypted with AES-256-GCM
Single sign-on and vault secretsEncrypted with AES-256-GCM
Target login credentialsEncrypted with AES-256-GCM
User passwordsHashed with bcrypt, never stored in plain form
Session and API tokensOnly hashes are stored, the raw token shows once

How it works in Cyberlop

When you save a credential, the app encrypts it with AES-256-GCM and keeps the encrypted value. The form never prints it back, so nobody can read a stored value from the screen, whether they are an administrator, a colleague or you. That is why fields show dots and say leave blank to keep current. A shield note on My Account says secrets are "encrypted at rest and never shown again after saving."

Git tokens get extra care in use. Cyberlop hands them to git for a single call and never writes them to disk. The token goes only to the hosts you allowed. Nowhere else. Application logs redact tokens, cookies and credentials.

Hashing works differently, and the difference is deliberate. You cannot reverse a hash, and that suits passwords and session tokens, which the app only ever needs to check and never needs to read back. See encryption at rest for the wider idea.

What to do next

  • Use read-only tokens, so a leak could do little harm.
  • Replace a credential by pasting a new one over the old one, then save the card and check it with a fresh scan. Read why you cannot see a saved token.
  • Check the details on the security page.

Questions that this page does not answer go to /contact.

Full tutorial

Account and organisation settings: notifications, retention, logo and plan

Step-by-step, with annotated screenshots.

Updated · Back to the help centre

Security question we did not answer?

Our team will answer it directly, or walk through it on a call with your security lead.