The current format for SCRAM verifiers in pg_authid is:

scram-sha-256:<salt>:<iteration count>:<StoredKey>:<ServerKey>

While reviewing Michael's patch to change that so that StoredKey and ServerKey are stored base64-encoded, rather than hex-encoded as they are currently [1], I looked again at RFC 5803. RFC 5803 specifies the format to use when storing SCRAM verifiers in LDAP. I looked at it earlier, and it was a source of inspiration for the current format, but I didn't think that it was directly applicable. I thought that in RFC 5803 the different fields were stored as separate fields or attributes, not as a single string.

But looking more closely, I think I misunderstood RFC 5803. It *does* in fact specify a single string format to store the verifier in. And the format looks like:

SCRAM-SHA-256$<iteration count>:<salt>$<StoredKey>:<ServerKey>

Alternating '$' and ':' as the separators seems a bit wonky, but it actually makes sense. "<iteration count>:<salt>" is treated as one field, and "<StoredKey>:<ServerKey>" is treated as another, which is logical, since the iteration count and salt are sent together to the client in the SCRAM challenge, while StoredKey and ServerKey must be kept secret.

I think we should adopt that exact format, so that our verifiers are compatible with RFC 5803. It doesn't make any immediate difference, but since there is a standard out there, might as well follow it. And just in case we get support for looking up SCRAM verifiers from an LDAP server in the future, it will come handy as we won't need to parse two different formats.

Barring objections, I'll go change our on-disk format for SCRAM verifiers to follow RFC 5803.


- Heikki

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to