PostgreSQL SCRAM-SHA-256 password hashing ignores server's scram_iterations setting

[ThomWright]

Describe the bug

When password_authentication is set to scram-sha-256, Vault hashes passwords client-side using SCRAM-SHA-256 with a hardcoded iteration count of 4096 (plugins/database/postgresql/scram/scram.go).

PostgreSQL 16 introduced the scram_iterations server parameter, allowing operators to configure the iteration count for password hashing (default 4096). Because Vault performs the hashing itself with a fixed value, the server's scram_iterations setting is effectively bypassed.

This matters in both directions:

• Operators who increase iterations for security get weaker hashing than expected, with no indication.
• Operators who decrease iterations for performance (e.g. when Vault rotates passwords frequently, making brute-force protection less relevant) are stuck paying the CPU cost of 4096 iterations per password creation/rotation, for negligible security gain.

In both cases, the operator has no reason to expect that their PostgreSQL server configuration is being ignored — the setting simply doesn't apply when the client sends a pre-hashed password.

To Reproduce

1. Configure PostgreSQL 16+ with a non-default scram_iterations value (e.g. SET scram_iterations = 100000 or SET scram_iterations = 1000)
2. Configure Vault's database secrets engine with password_authentication = scram-sha-256
3. Create or rotate a user's password via Vault
4. Inspect the stored password hash in pg_authid — the iteration count will be 4096 regardless of the server setting

Expected behavior

I expected Vault to respect the server's scram_iterations setting by default.

Ideally, Vault would also allow an explicit override via its own configuration, for cases where the operator wants Vault to use a different value than the server's configured value.

Environment:

• Vault Server Version (retrieve with vault status): Latest (v1.21.4)
• Vault CLI Version (retrieve with vault version): N/A
• Server Operating System/Architecture: All

Vault server configuration file(s): N/A

Additional context

The hardcoded constant is at plugins/database/postgresql/scram/scram.go:30. The scram.Hash() function signature doesn't accept an iteration parameter.

[dosubot]

Thanks for the detailed bug report! I can confirm your findings — the iteration count is hardcoded to 4096 in plugins/database/postgresql/scram/scram.go, and the Hash() function doesn't accept an iteration parameter:

func Hash(password string) (string, error) {
    salt, err := genSalt(saltSize)
    if err != nil {
        return "", err
    }
    hashedPassword := hashPassword([]byte(password), salt, iterationCnt, digestLen)
    return hashedPassword, nil
}

There's currently no configuration option for this — password_authentication only accepts "password" or "scram-sha-256" with no way to customize SCRAM parameters.

I didn't find any existing issues or PRs addressing this, so this appears to be a new feature request. Your suggestion to both respect the server's scram_iterations by default and allow an explicit override in Vault's configuration would give operators full flexibility.

@heatherezell will get this added to the engineers for review.

Written by @dosu, edited by heatherezell

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}