nullcipher

Passwords and keys inside connection strings, URLs and commands

Only the password or key inside postgres://user:password@host, an Azure connection string or SAS URL, an S3 presigned URL, curl -u, --password, mysql -p or .netrc. Host, user, port and database stay. Below: the exact rule, a live check, why it matters, and what to do if one already leaked.

Live check: Password or key in a connection string, URL or command

What an AI chat would receive after masking

postgres://app:[CONN_SECRET_1]@db.example.com:5432/orders
DefaultEndpointsProtocol=https;AccountName=examplestore;AccountKey=[CONN_SECRET_2];EndpointSuffix=core.windows.net
curl -u admin:[CONN_SECRET_3] api.example.com/health

3 × Password or key in a connection string, URL or command found and masked.

How nullcipher recognises it

Only the secret part of: the password in scheme://user:password@host (also redis://:password@host with no user); Password, Pwd, AccountKey and SharedAccessKey in Key=Value;Key=Value connection strings (AccountKey= and SharedAccessKey= also on their own, up to the first space); the sig of an Azure SAS URL and the X-Amz-Signature of an S3 presigned URL; the password in -u or --user user:password (not docker's -u uid:gid); --password=VALUE (never --password-stdin); --password VALUE after a command whose --password takes the next word (docker, podman or oras login, helm, az, wget and similar — not psql, whose --password takes nothing, nor mysql, whose takes a value only after =), and -p VALUE after docker login; mysql or mariadb -pPASSWORD written with no space; and a .netrc password after machine … login …. Scheme, user, host, port, path, database name and the other parameters stay readable. curl -u user with no colon, and mysql -p followed by a space (mysql then prompts), have nothing to hide.

This is the rule text of the “Password or key in a connection string, URL or command” 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)

postgres://app:EXAMPLE-pass@db.example.com:5432/orders
DefaultEndpointsProtocol=https;AccountName=examplestore;AccountKey=EXAMPLEnotarealkey0000==;EndpointSuffix=core.windows.net
curl -u admin:EXAMPLEpass api.example.com/health

nullcipher replaces it with [CONN_SECRET_1] and [CONN_SECRET_2] and [CONN_SECRET_3]. Every secret contains the word EXAMPLE. After masking, the scheme, user app, host db.example.com, port 5432, database orders, AccountName, EndpointSuffix, the curl user admin and the URL are all still there: enough for an AI to find a wrong port or a typo in the host.

Why it matters in an AI chat

A connection string or a command line is exactly what gets pasted when a connection fails, and it carries the host, the user and the password in one line. With only the password hidden, postgres://app:[CONN_SECRET_1]@db.example.com:5432/orders still lets the AI spot a wrong port, a missing sslmode or a misspelt database name.

Some of these are worth more than a password. Microsoft's documentation says access to a storage account's shared key (AccountKey) grants full access to that account's data, and the key can sign new SAS tokens. A SAS sig or an S3 X-Amz-Signature is narrower but needs nothing else: AWS describes presigned URLs as bearer tokens that grant access to those who possess them, reusable until they expire, which is up to 7 days when made with the AWS CLI or an SDK.

Command-line passwords leak in more places than the chat. MySQL's manual warns that -ppassword and --password=password can be visible to ps, and Docker's reference recommends --password-stdin so the password stays out of shell history and log files. nullcipher masks only the password in -pS3cret, and leaves mysql -p mydb (which prompts) and curl -u bob (which prompts) alone.

If it already leaked

  1. A database, broker or service password (postgres://, mongodb+srv://, redis://, amqp://, mysql -p, curl -u, --password, .netrc): change that user's password on the server itself, then update every config file and secret store that holds it, and look at the server's login log for connections since the paste.
  2. An Azure storage AccountKey: rotate it. Microsoft's steps are to point your applications at the secondary key, regenerate the primary key (portal: Security + networking → Access keys → Regenerate), move the applications to the new primary, then regenerate the secondary. Regenerating a key also revokes every account and service SAS that was signed with it. [1]
  3. An Azure SAS URL: a service SAS tied to a stored access policy can be revoked by changing or deleting that policy, without touching the account key. An ad hoc SAS carries its own expiry (the se= parameter) and stays valid until then unless you regenerate the key that signed it. [2][1]
  4. An S3 presigned URL: it keeps working until its expiry time or until the credential that signed it is revoked, deleted or deactivated, whichever comes first. To kill it early, deactivate or delete the access key named in its X-Amz-Credential parameter and issue a new one. [3]
  5. Next time, keep the password off the command line: mysql -u root -p with nothing after -p prompts for it, docker login --password-stdin reads it from standard input, and curl -u admin with no colon makes curl prompt. [4][5][6]

Sources

  1. Manage account access keys — Azure Storage, Microsoft Learn — checked 2026-09-23.
  2. Grant limited access to data with shared access signatures (SAS) — Azure Storage, Microsoft Learn — checked 2026-09-23.
  3. Download and upload objects with presigned URLs — Amazon S3 User Guide — checked 2026-09-23.
  4. End-User Guidelines for Password Security — MySQL 8.4 Reference Manual, section 8.1.2.1 — checked 2026-09-23.
  5. docker login — Docker Docs CLI reference — checked 2026-09-23.
  6. curl man page, -u, --user — checked 2026-09-23.

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 30 secret types and how to delete a chat you already sent.