nullcipher

Passwords and secrets in config lines (DB_PASSWORD=, client_secret:, --token=)

The value after a key that names a secret (password, secret, token, api_key…), plus passwords in connection strings. Below: the exact rule, a live check, why it matters, and what to do if one already leaked.

Live check: Password or secret in config

What an AI chat would receive after masking

DB_PASSWORD=[PASSWORD_1]
api_key: "[SECRET_1]"

2 × Password or secret in config found and masked.

How nullcipher recognises it

The value after a key that names a secret — password, passwd, pwd, pass, passphrase, secret, token, api_key, access_key, private_key — in KEY=value, key: value, "key": "value" and --key=value shapes; also the password in scheme://user:password@host, a Bearer token and a Basic credential. The key stays, the value is masked. Booleans, null, ${VAR} references and code expressions are left alone.

This is the rule text of the “Password or secret in config” detector in the masking engine, copied from the engine when this page was built. Detectors run in a fixed order and, where two overlap, the earlier one wins.

Example (fake)

DB_PASSWORD=EXAMPLE-not-a-real-password
api_key: "EXAMPLE0000notreal"

nullcipher replaces it with [PASSWORD_1] and [SECRET_1]. Both values contain the word EXAMPLE. Note that the key names stay visible after masking, so the AI still understands what each line configures.

Why it matters in an AI chat

A password in a .env file, a docker-compose file or a connection string belongs to a database or service that is reachable from wherever that config runs. The line usually says which host, too.

These values have no fixed prefix, so they can only be found by the key in front of them. nullcipher masks the value after keys such as DB_PASSWORD=, client_secret: or --token=; a password written in a sentence, or under a key name it does not recognise, goes through unmasked.

People reuse passwords. One database password in a pasted file can open more than one door.

If it already leaked

  1. Change the password or secret on the system it belongs to — the database user, the service account, the OAuth client — then update every config and secret store that holds it.
  2. If the same password is used anywhere else, change it there too.
  3. Look at that system's login or access logs for connections you do not recognise since the paste.
  4. For a Bearer token or a Basic credential copied from a request, revoke that token or change that account's password at the service that issued it.

Open the full masking tool to mask a whole log, .env file or e-mail — every type at once — and restore the values in the AI's answer. Or see all 16 secret types and how to delete a chat you already sent.