Thread

Commits

  1. Increase SCRAM salt length

  2. Make SCRAM salts and nonces longer.

  1. SCRAM salt length

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2017-08-16T13:10:51Z

    The SCRAM salt length is currently set as
    
    /* length of salt when generating new verifiers */
    #define SCRAM_DEFAULT_SALT_LEN     12
    
    without further comment.
    
    I suspect that this length was chosen based on the example in RFC 5802
    (SCRAM-SHA-1) section 5.  But the analogous example in RFC 7677
    (SCRAM-SHA-256) section 3 uses a length of 16.  Should we use that instead?
    
    -- 
    Peter Eisentraut              http://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
    
    
    
  2. Re: SCRAM salt length

    Aleksander Alekseev <a.alekseev@postgrespro.ru> — 2017-08-16T15:10:29Z

    He Peter,
    
    > The SCRAM salt length is currently set as
    > 
    > /* length of salt when generating new verifiers */
    > #define SCRAM_DEFAULT_SALT_LEN     12
    > 
    > without further comment.
    > 
    > I suspect that this length was chosen based on the example in RFC 5802
    > (SCRAM-SHA-1) section 5.  But the analogous example in RFC 7677
    > (SCRAM-SHA-256) section 3 uses a length of 16.  Should we use that instead?
    
    Maybe this length was chosen just because it becomes a 16-characters
    string after base64encode. If I understand correctly RFC 5802 and RFC
    7677 don't say much about the required or recommended length of the
    salt.
    
    I personally believe that 2^96 of possible salts is consistent with both
    RFCs and should be enough in practice.
    
    -- 
    Best regards,
    Aleksander Alekseev
    
  3. Re: SCRAM salt length

    Michael Paquier <michael.paquier@gmail.com> — 2017-08-17T02:42:39Z

    On Thu, Aug 17, 2017 at 12:10 AM, Aleksander Alekseev
    <a.alekseev@postgrespro.ru> wrote:
    >> The SCRAM salt length is currently set as
    >>
    >> /* length of salt when generating new verifiers */
    >> #define SCRAM_DEFAULT_SALT_LEN     12
    >>
    >> without further comment.
    >>
    >> I suspect that this length was chosen based on the example in RFC 5802
    >> (SCRAM-SHA-1) section 5.  But the analogous example in RFC 7677
    >> (SCRAM-SHA-256) section 3 uses a length of 16.  Should we use that instead?
    
    In the initial discussions there was as well a mention about using 16 bytes.
    https://www.postgresql.org/message-id/507550BD.2030401@vmware.com
    As we are using SCRAM-SHA-256, let's bump it up and be consistent.
    That's now or never.
    
    > Maybe this length was chosen just because it becomes a 16-characters
    > string after base64encode. If I understand correctly RFC 5802 and RFC
    > 7677 don't say much about the required or recommended length of the
    > salt.
    
    Yep, it doesn't provide any recommendation.
    
    > I personally believe that 2^96 of possible salts is consistent with both
    > RFCs and should be enough in practice.
    
    (12 bytes * 8) = 96, so you would favor 12 as length.
    -- 
    Michael
    
    
    
  4. Re: SCRAM salt length

    Simon Riggs <simon@2ndquadrant.com> — 2017-08-17T07:41:54Z

    On 16 August 2017 at 14:10, Peter Eisentraut
    <peter.eisentraut@2ndquadrant.com> wrote:
    > The SCRAM salt length is currently set as
    >
    > /* length of salt when generating new verifiers */
    > #define SCRAM_DEFAULT_SALT_LEN     12
    >
    > without further comment.
    >
    > I suspect that this length was chosen based on the example in RFC 5802
    > (SCRAM-SHA-1) section 5.  But the analogous example in RFC 7677
    > (SCRAM-SHA-256) section 3 uses a length of 16.  Should we use that instead?
    
    16 preferred, IMHO
    
    -- 
    Simon Riggs                http://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
    
    
    
  5. Re: SCRAM salt length

    Robert Haas <robertmhaas@gmail.com> — 2017-08-17T13:04:13Z

    On Wed, Aug 16, 2017 at 10:42 PM, Michael Paquier
    <michael.paquier@gmail.com> wrote:
    > In the initial discussions there was as well a mention about using 16 bytes.
    > https://www.postgresql.org/message-id/507550BD.2030401@vmware.com
    > As we are using SCRAM-SHA-256, let's bump it up and be consistent.
    > That's now or never.
    
    This was discussed and changed once before at
    https://www.postgresql.org/message-id/df8c6e27-4d8e-5281-96e5-131a4e638fc8@8kdata.com
    
    -- 
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company
    
    
    
  6. Re: SCRAM salt length

    Heikki Linnakangas <hlinnaka@iki.fi> — 2017-08-17T13:21:43Z

    On 08/17/2017 04:04 PM, Robert Haas wrote:
    > On Wed, Aug 16, 2017 at 10:42 PM, Michael Paquier
    > <michael.paquier@gmail.com> wrote:
    >> In the initial discussions there was as well a mention about using 16 bytes.
    >> https://www.postgresql.org/message-id/507550BD.2030401@vmware.com
    >> As we are using SCRAM-SHA-256, let's bump it up and be consistent.
    >> That's now or never.
    > 
    > This was discussed and changed once before at
    > https://www.postgresql.org/message-id/df8c6e27-4d8e-5281-96e5-131a4e638fc8@8kdata.com
    
    Different thing. That was the nonce length, now we're talking about salt 
    length.
    
    I think 2^96 is large enough. The RFC doesn't say anything about salt 
    length, but the one example in it uses a 16 byte string as the salt. 
    That's more or less equal to the current default of 12 raw bytes, after 
    base64-encoding.
    
    On 08/17/2017 05:42 AM, Michael Paquier wrote:
     > That's now or never.
    
    Not really. That constant is just the default to use when creating new 
    password verifiers, but the code can handle any salt length, and 
    different verifiers can have different lengths.
    
    - Heikki
    
    
    
  7. Re: SCRAM salt length

    Robert Haas <robertmhaas@gmail.com> — 2017-08-17T14:03:53Z

    On Thu, Aug 17, 2017 at 9:21 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
    > Different thing. That was the nonce length, now we're talking about salt
    > length.
    
    Actually that commit (0557a5dc2cf845639d384801b6861ebbd35dc7ee) changed both:
    
    -#define SCRAM_RAW_NONCE_LEN         10
    +#define SCRAM_RAW_NONCE_LEN         18
    
     /* length of salt when generating new verifiers */
    -#define SCRAM_DEFAULT_SALT_LEN      10
    +#define SCRAM_DEFAULT_SALT_LEN      12
    
    I don't think I understand exactly how they're different; especially,
    I don't quite understand how the nonce is used.
    
    -- 
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company
    
    
    
  8. Re: SCRAM salt length

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2017-08-17T14:23:46Z

    On 8/17/17 09:21, Heikki Linnakangas wrote:
    > The RFC doesn't say anything about salt 
    > length, but the one example in it uses a 16 byte string as the salt. 
    > That's more or less equal to the current default of 12 raw bytes, after 
    > base64-encoding.
    
    The example is
    
       S: r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0,
          s=W22ZaJ0SNY7soEsUEjb6gQ==,i=4096
    
    That salt is 24 characters and 16 raw bytes.
    
    -- 
    Peter Eisentraut              http://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
    
    
    
  9. Re: SCRAM salt length

    Michael Paquier <michael.paquier@gmail.com> — 2017-08-17T14:28:23Z

    On Thu, Aug 17, 2017 at 10:21 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
    > On 08/17/2017 05:42 AM, Michael Paquier wrote:
    >> That's now or never.
    >
    > Not really. That constant is just the default to use when creating new
    > password verifiers, but the code can handle any salt length, and different
    > verifiers can have different lengths.
    
    Indeed, fuzzy memory here. I thought that parse_scram_verifier()
    checked the salt length with the default value, but that's not the
    case. Perhaps at some point in the development there was a check of
    this kind..
    -- 
    Michael
    
    
    
  10. Re: SCRAM salt length

    Heikki Linnakangas <hlinnaka@iki.fi> — 2017-08-17T16:10:09Z

    On 08/17/2017 05:23 PM, Peter Eisentraut wrote:
    > On 8/17/17 09:21, Heikki Linnakangas wrote:
    >> The RFC doesn't say anything about salt
    >> length, but the one example in it uses a 16 byte string as the salt.
    >> That's more or less equal to the current default of 12 raw bytes, after
    >> base64-encoding.
    > 
    > The example is
    > 
    >     S: r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0,
    >        s=W22ZaJ0SNY7soEsUEjb6gQ==,i=4096
    > 
    > That salt is 24 characters and 16 raw bytes.
    
    Ah, I see, that's from the SCRAM-SHA-256 spec. I was looking at the 
    example in the original SCRAM-SHA-1 spec:
    
    S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,
           i=4096
    
    - Heikki
    
    
    
  11. Re: SCRAM salt length

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2017-08-17T20:50:52Z

    On 8/17/17 12:10, Heikki Linnakangas wrote:
    > On 08/17/2017 05:23 PM, Peter Eisentraut wrote:
    >> On 8/17/17 09:21, Heikki Linnakangas wrote:
    >>> The RFC doesn't say anything about salt
    >>> length, but the one example in it uses a 16 byte string as the salt.
    >>> That's more or less equal to the current default of 12 raw bytes, after
    >>> base64-encoding.
    >>
    >> The example is
    >>
    >>     S: r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0,
    >>        s=W22ZaJ0SNY7soEsUEjb6gQ==,i=4096
    >>
    >> That salt is 24 characters and 16 raw bytes.
    > 
    > Ah, I see, that's from the SCRAM-SHA-256 spec. I was looking at the 
    > example in the original SCRAM-SHA-1 spec:
    > 
    > S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,
    >        i=4096
    
    Hence my original inquiry: "I suspect that this length was chosen based
    on the example in RFC 5802 (SCRAM-SHA-1) section 5.  But the analogous
    example in RFC 7677 (SCRAM-SHA-256) section 3 uses a length of 16.
    Should we use that instead?"
    
    -- 
    Peter Eisentraut              http://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
    
    
    
  12. Re: SCRAM salt length

    Joe Conway <mail@joeconway.com> — 2017-08-17T21:00:31Z

    On 08/17/2017 01:50 PM, Peter Eisentraut wrote:
    > On 8/17/17 12:10, Heikki Linnakangas wrote:
    >> On 08/17/2017 05:23 PM, Peter Eisentraut wrote:
    >>> On 8/17/17 09:21, Heikki Linnakangas wrote:
    >>>> The RFC doesn't say anything about salt
    >>>> length, but the one example in it uses a 16 byte string as the salt.
    >>>> That's more or less equal to the current default of 12 raw bytes, after
    >>>> base64-encoding.
    >>>
    >>> The example is
    >>>
    >>>     S: r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0,
    >>>        s=W22ZaJ0SNY7soEsUEjb6gQ==,i=4096
    >>>
    >>> That salt is 24 characters and 16 raw bytes.
    >> 
    >> Ah, I see, that's from the SCRAM-SHA-256 spec. I was looking at the 
    >> example in the original SCRAM-SHA-1 spec:
    >> 
    >> S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,
    >>        i=4096
    > 
    > Hence my original inquiry: "I suspect that this length was chosen based
    > on the example in RFC 5802 (SCRAM-SHA-1) section 5.  But the analogous
    > example in RFC 7677 (SCRAM-SHA-256) section 3 uses a length of 16.
    > Should we use that instead?"
    
    Unless there is some significant downside to using 16 byte salt, that
    would be my vote.
    
    Joe
    
    -- 
    Crunchy Data - http://crunchydata.com
    PostgreSQL Support for Secure Enterprises
    Consulting, Training, & Open Source Development
    
    
  13. Re: SCRAM salt length

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2017-08-24T18:22:17Z

    On 8/17/17 17:00, Joe Conway wrote:
    >> Hence my original inquiry: "I suspect that this length was chosen based
    >> on the example in RFC 5802 (SCRAM-SHA-1) section 5.  But the analogous
    >> example in RFC 7677 (SCRAM-SHA-256) section 3 uses a length of 16.
    >> Should we use that instead?"
    > Unless there is some significant downside to using 16 byte salt, that
    > would be my vote.
    
    committed
    
    -- 
    Peter Eisentraut              http://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services