Thread: use of the term "verifier" with SCRAM
I'm confused by how the code uses the term "verifier" in relation to SCRAM.
ISTM that the code uses the term as meaning whatever is or would be
stored in pg_auth.rolpassword.
I don't see this usage supported in the RFCs. In RFC 5802,
verifier = "v=" base64
;; base-64 encoded ServerSignature.
where
ServerSignature := HMAC(ServerKey, AuthMessage)
ServerKey := HMAC(SaltedPassword, "Server Key")
AuthMessage := client-first-message-bare + "," +
server-first-message + "," +
client-final-message-without-proof
whereas what is stored in rolpassword is
SCRAM-SHA-256$<iterations>:<salt>$<storedkey>:<serverkey>
where
StoredKey := H(ClientKey)
ClientKey := HMAC(SaltedPassword, "Client Key")
So while these are all related, I don't think it's accurate to call what
is in rolpassword a SCRAM "verifier".
RFC 5803 is titled "Lightweight Directory Access Protocol (LDAP) Schema
for Storing Salted Challenge Response Authentication Mechanism (SCRAM)
Secrets". Following that, I think calling the contents of rolpassword a
"secret" or a "stored secret" would be better.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 14/08/2019 08:59, Peter Eisentraut wrote:
> I'm confused by how the code uses the term "verifier" in relation to SCRAM.
>
> ISTM that the code uses the term as meaning whatever is or would be
> stored in pg_auth.rolpassword.
>
> I don't see this usage supported in the RFCs. In RFC 5802,
>
> verifier = "v=" base64
> ;; base-64 encoded ServerSignature.
>
> where
>
> ServerSignature := HMAC(ServerKey, AuthMessage)
> ServerKey := HMAC(SaltedPassword, "Server Key")
> AuthMessage := client-first-message-bare + "," +
> server-first-message + "," +
> client-final-message-without-proof
>
> whereas what is stored in rolpassword is
>
> SCRAM-SHA-256$<iterations>:<salt>$<storedkey>:<serverkey>
>
> where
>
> StoredKey := H(ClientKey)
> ClientKey := HMAC(SaltedPassword, "Client Key")
>
> So while these are all related, I don't think it's accurate to call what
> is in rolpassword a SCRAM "verifier".
Huh, you're right.
> RFC 5803 is titled "Lightweight Directory Access Protocol (LDAP) Schema
> for Storing Salted Challenge Response Authentication Mechanism (SCRAM)
> Secrets". Following that, I think calling the contents of rolpassword a
> "secret" or a "stored secret" would be better.
RFC 5802 uses the term "Authentication information". See section "2.1
Terminology":
o Authentication information: Information used to verify an identity
claimed by a SCRAM client. The authentication information for a
SCRAM identity consists of salt, iteration count, "StoredKey" and
"ServerKey" (as defined in the algorithm overview) for each
supported cryptographic hash function.
But I agree that "secret", as used in RFC5803 is better.
- Heikki
On 2019-08-14 10:41, Heikki Linnakangas wrote: >> RFC 5803 is titled "Lightweight Directory Access Protocol (LDAP) Schema >> for Storing Salted Challenge Response Authentication Mechanism (SCRAM) >> Secrets". Following that, I think calling the contents of rolpassword a >> "secret" or a "stored secret" would be better. > But I agree that "secret", as used in RFC5803 is better. Here is my proposed patch to adjust this. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
On Thu, Oct 10, 2019 at 09:08:37AM +0200, Peter Eisentraut wrote: > Here is my proposed patch to adjust this. Looks fine to me reading through. I think that you are right to not change the descriptions in build_server_final_message(), as that's described similarly in RFC 5802. By renaming scram_build_verifier() to scram_build_secret() you are going to break one of my in-house extensions. I am using it to register for a user SCRAM veri^D^D^D^D secrets with custom iteration and salt length :) -- Michael
Attachment
On 2019-10-10 10:03, Michael Paquier wrote: > On Thu, Oct 10, 2019 at 09:08:37AM +0200, Peter Eisentraut wrote: >> Here is my proposed patch to adjust this. > > Looks fine to me reading through. I think that you are right to not > change the descriptions in build_server_final_message(), as that's > described similarly in RFC 5802. committed > By renaming scram_build_verifier() > to scram_build_secret() you are going to break one of my in-house > extensions. I am using it to register for a user SCRAM veri^D^D^D^D > secrets with custom iteration and salt length :) OK, that should be easy to work around with an #ifdef or two. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services