Parameter · Connections and Authentication / Authentication
scram_iterations
Sets the iteration count for SCRAM secret generation.
- Default:
4096 - Type: integer
- Range: 1 … 2147483647
- Applies: Session (any user)
In plain words
How many hashing rounds go into a SCRAM password secret. More rounds make each login a little slower for the client, and make guessing passwords from a stolen hash much slower for an attacker.
Only new or changed passwords use the new value.
For DBAs and operators
Added in PostgreSQL 16 (before that it was fixed at 4096, the RFC 7677 minimum). The count is stored inside the secret (SCRAM-SHA-256$<iterations>:<salt>$<StoredKey>:<ServerKey>) and sent to the client with the salt during login; the client performs the PBKDF2 work, the server only does a few HMACs. So raising it mainly costs client CPU per new connection (relevant for apps that open many short connections without a pooler) and multiplies offline brute-force cost against a leaked pg_authid.
It is a user-context setting, so you can raise it just while setting a password:
SET scram_iterations = 100000;
ALTER ROLE app PASSWORD 'new-secret'; -- or \password app
SELECT rolname, split_part(rolpassword, ':', 1) FROM pg_authid WHERE rolname = 'app';Note: if a client-side tool hashes the password itself (psql \password, libpq PQencryptPasswordConn), the iteration count is chosen by the client; libpq 16+ uses the server's scram_iterations, which the server reports to it at connection time. Mixed counts across roles can reveal to an unauthenticated user which role names exist (the server answers with the stored count), so keep them uniform if that matters.
How to change it
Any user can change it for their session with SET.