lolcreds

Public credential defaults and exposure patterns for authorized security testing.

ClickHouse

ClickHousedatabase4 credentials1 default credential

Credentials4 documented
01

Default User with Blank Password

clickhouse / default-user-blank-password

ClickHouse packages include a default user. Many default/example configurations allow the default user with no password, especially for local or development deployments, until operators configure users.xml/users.d secrets.

static defaultuser definedsecretusername/password

Default credentials

default

Location

public interface
ClickHouse native TCP, HTTP interface, clickhouse-client, JDBC/ODBC, and web integrations
config file
users.xml, users.d/*.xml

user password, password_sha256_hex, networks, profiles, and quotas

secret store

Kubernetes Secrets, ClickHouse Keeper/ZooKeeper stores, and password vaults

logs

query_log, text_log, server logs, and authentication failures

Notes

Treat this as a default/no-password configuration risk: the default user name exists and the password is absent, so `default.password` is null rather than an empty-string credential. Hardened production deployments should set a password or external authentication.

02

ClickHouse User Password / Hash

clickhouse / user-password-hash

ClickHouse users can be configured with plaintext passwords, SHA256/double-SHA1 hashes, LDAP/Kerberos, or SQL-managed access control.

user definedgenerated on installsecretusername/password

Looks like

pattern
pattern

ClickHouse XML user password or password hash field

<password(_sha256_hex|_double_sha1_hex)?>[^<]*</password(_sha256_hex|_double_sha1_hex)?>
pattern

ClickHouse SQL user creation syntax containing an authentication secret

IDENTIFIED\s+WITH\s+\w+\s+BY

Location

config file
users.xml, users.d/*.xml, config.xml

local users, LDAP/Kerberos auth, interserver credentials, and profiles

database

SQL access-control storage and system tables for users/roles where enabled

public interface
native TCP, HTTP API, SQL clients, and cluster interserver endpoints
secret store

Kubernetes Secrets, cloud secret managers, and password vaults

source code

deployment manifests, application configs, and test fixtures

03

Interserver / Replication / Keeper Secret

clickhouse / interserver-replication-secret

ClickHouse clusters use interserver HTTP credentials, distributed DDL/Keeper/ZooKeeper credentials, macros, TLS keys, and replication secrets for node-to-node operations.

user definedgenerated on installsecretsecret value

Location

config file
config.xml, conf.d/*.xml

interserver_http_credentials, remote_servers secrets, Keeper/ZooKeeper auth, and cluster config

secret store

Kubernetes Secrets, Keeper/ZooKeeper ACL stores, and deployment vaults

logs

replication, distributed DDL, Keeper, and interserver logs

04

TLS Private Key

clickhouse / tls-private-key

ClickHouse can use TLS certificates/private keys for native, HTTPS, interserver, and Keeper communication.

generated on installuser definedsecretkey pair

Looks like

pattern
pattern

private key material for ClickHouse TLS server/client or interserver authentication

-----BEGIN (RSA |EC |ENCRYPTED |)PRIVATE KEY-----

Location

config file
config.xml, certs/

openSSL server/client key files and TLS settings

secret store

Kubernetes Secrets, certificate stores, and vaults

artifact

cluster backups and diagnostics bundles

Scope

Authorized use

LOLCreds helps map the credential surface of real products: known defaults, generated values, credential locations, and exposure patterns.