Thread: [HACKERS] On-disk format of SCRAM verifiers
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. [1] https://www.postgresql.org/message-id/CAB7nPqSbsCBCxy8-DtwzRxYgTnbGUtY4uFEkLQhG%3DR%3Duo%3Dg8Fw%40mail.gmail.com - Heikki
Heikki, * Heikki Linnakangas (hlinnaka@iki.fi) wrote: > 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. +1 > 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. Agreed. Thanks! Stephen
On 21 April 2017 at 10:20, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > 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> Could you explain where you are looking? I don't see that in RFC5803 -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Apr 21, 2017 at 10:02 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 21 April 2017 at 10:20, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> 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>
>
> Could you explain where you are looking? I don't see that in RFC5803
From 1. Overview:
Syntax of the attribute can be expressed using ABNF [RFC5234]. Non- terminal references in the following ABNF are
definedin either [AUTHPASS], [RFC4422], or [RFC5234].
scram-mech = "SCRAM-SHA-1" / scram-mech-ext ; Complies with ABNF for <scheme>
; defined in [AUTHPASS].
scram-authInfo = iter-count ":" salt ; Complies with ABNF for <authInfo>
;defined in [AUTHPASS].
scram-authValue = stored-key ":" server-key ; Complies with ABNF for <authValue>
; defined in [AUTHPASS].
Thanks,
--
Michael
On Fri, Apr 21, 2017 at 9:25 PM, Stephen Frost <sfrost@snowman.net> wrote: > * Heikki Linnakangas (hlinnaka@iki.fi) wrote: >> 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. > > +1 > >> 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. > > Agreed. +1 to all that. Consistency is a good thing. -- Michael
On 21 April 2017 at 14:20, Michael Paquier <michael.paquier@gmail.com> wrote: > On Fri, Apr 21, 2017 at 10:02 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >> On 21 April 2017 at 10:20, Heikki Linnakangas <hlinnaka@iki.fi> wrote: >>> 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> >> >> Could you explain where you are looking? I don't see that in RFC5803 > > From 1. Overview: > > Syntax of the attribute can be expressed using ABNF [RFC5234]. Non- > terminal references in the following ABNF are defined in either > [AUTHPASS], [RFC4422], or [RFC5234]. > > scram-mech = "SCRAM-SHA-1" / scram-mech-ext > ; Complies with ABNF for <scheme> > ; defined in [AUTHPASS]. > > scram-authInfo = iter-count ":" salt > ; Complies with ABNF for <authInfo> > ; defined in [AUTHPASS]. > > scram-authValue = stored-key ":" server-key > ; Complies with ABNF for <authValue> > ; defined in [AUTHPASS]. > > Thanks, The above text, which I've already read, does not explain the suggested change from : to $. Could you explain? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 21 April 2017 16:20:56 EEST, Michael Paquier <michael.paquier@gmail.com> wrote: >On Fri, Apr 21, 2017 at 10:02 PM, Simon Riggs <simon@2ndquadrant.com> >wrote: >> On 21 April 2017 at 10:20, Heikki Linnakangas <hlinnaka@iki.fi> >wrote: >>> 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> >> >> Could you explain where you are looking? I don't see that in RFC5803 > >From 1. Overview: Yeah, it's not easy to see, I missed it earlier too. You have to look at RFC 5803 and RFC 3112 together. RFC 3112 says thatthe overall format is "<scheme>$<authInfo>$<authValue>", and RFC5803 says that for SCRAM, scheme is "SCRAM-SHA-256" (forour variant), authInfo is "<iteration count>:<salt>" and authValue is "<StoredKey>:<ServerKey>" They really should've included examples in those RFCs. - Heikki
Re: [HACKERS] On-disk format of SCRAM verifiers
From
ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Date:
Michael Paquier <michael.paquier@gmail.com> writes:
> On Fri, Apr 21, 2017 at 10:02 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On 21 April 2017 at 10:20, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>> 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>
>>
>> Could you explain where you are looking? I don't see that in RFC5803
>
> From 1. Overview:
>
> Syntax of the attribute can be expressed using ABNF [RFC5234]. Non-
> terminal references in the following ABNF are defined in either
> [AUTHPASS], [RFC4422], or [RFC5234].
>
> scram-mech = "SCRAM-SHA-1" / scram-mech-ext
> ; Complies with ABNF for <scheme>
> ; defined in [AUTHPASS].
>
> scram-authInfo = iter-count ":" salt
> ; Complies with ABNF for <authInfo>
> ; defined in [AUTHPASS].
>
> scram-authValue = stored-key ":" server-key
> ; Complies with ABNF for <authValue>
> ; defined in [AUTHPASS].
And scram-mech, scram-authInfo and scram-authValue are used as the
"scheme", "authInfo" and "authValue" parts as specified in [AUTHPASS]
(RFC3112):
authPasswordValue = w scheme s authInfo s authValue w scheme = %x30-39 / %x41-5A / %x2D-2F / %x5F
; 0-9, A-Z, "-", ".", "/", or "_" authInfo = schemeSpecificValue authValue
=schemeSpecificValue schemeSpecificValue = *( %x21-23 / %x25-7E ) ; printable ASCII less "$"
and" " s = w SEP w w = *SP SEP = %x24 ; "$" SP = %x20 ; " " (space)
> Thanks,
> --
> Michael
- ilmari
--
"A disappointingly low fraction of the human race is,at any given time, on fire." - Stig Sandbeck Mathisen
On 21 April 2017 at 14:42, Heikki Linnakangas <hlinnaka@iki.fi> wrote: >>>> SCRAM-SHA-256$<iteration count>:<salt>$<StoredKey>:<ServerKey> >>> >>> Could you explain where you are looking? I don't see that in RFC5803 >> > >From 1. Overview: > > Yeah, it's not easy to see, I missed it earlier too. You have to look at RFC 5803 and RFC 3112 together. RFC 3112 saysthat the overall format is "<scheme>$<authInfo>$<authValue>", and RFC5803 says that for SCRAM, scheme is "SCRAM-SHA-256"(for our variant), authInfo is "<iteration count>:<salt>" and authValue is "<StoredKey>:<ServerKey>" > > They really should've included examples in those RFCs. Thanks +1 for change -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 04/21/2017 05:33 PM, Simon Riggs wrote: > On 21 April 2017 at 14:42, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > >>>>> SCRAM-SHA-256$<iteration count>:<salt>$<StoredKey>:<ServerKey> >>>> >>>> Could you explain where you are looking? I don't see that in RFC5803 >>> >> >From 1. Overview: >> >> Yeah, it's not easy to see, I missed it earlier too. You have to look at RFC 5803 and RFC 3112 together. RFC 3112 saysthat the overall format is "<scheme>$<authInfo>$<authValue>", and RFC5803 says that for SCRAM, scheme is "SCRAM-SHA-256"(for our variant), authInfo is "<iteration count>:<salt>" and authValue is "<StoredKey>:<ServerKey>" >> >> They really should've included examples in those RFCs. > > Thanks > > +1 for change Committed, thanks. - Heikki