Subject: [kitten] Comments on draft-ietf-kitten-password-storage-01

From: Alexey Melnikov <[email-masked]>
Date: Tue, 3 Nov 2020 14:56:38 +0000

Hi Sam,

I just had a quick read of -01. There are some things I need to think 
about and might comment on later on.

But a few small questions/comments below:

> 4.2.  Storage
>
>    Servers MUST always store passwords only after they have been salted
>    and hashed using a strong KDF.  A distinct salt SHOULD be used for
>    each user, and each SCRAM family supported.  Salts SHOULD be
>    generated using a cryptographically secure random number generator.
>    The salt MAY be stored in the same datastore as the password. If it
>    is stored alongside the password, it SHOULD be combined with a pepper
>    stored in the application configuration, or a secure location other
>    than the datastore containing the salts.
Can you describe in more details what the last quoted sentence means for 
a server SCRAM implementation? Does this mean reading (or deriving) salt 
for a particular user and appending pepper to it, then using the 
combined string as SCRAM salt? Either way, I think you should either 
give an example or clarify with text.
> 5.3.  PBKDF2
>
>    PBKDF2 [RFC8018] is used by the SCRAM [RFC5802] family of SASL
>    mechanisms.
>
> +=============================+==================================+
>     |          Parameter          | Value               |
> +=============================+==================================+
>     | Minimum iteration count (c) | 10,000                           |

Sorry, I might have missed this discussion, but I am curious to know 
where this number came from. (And a note to myself: I should update 
SCRAM-SHA-512 draft to match).

Best Regards,

Alexey

---

From: [email-masked]
Date: Tue, 3 Nov 2020 18:54:30 -0600 (CST)

> On 11/03/2020 8:56 AM Alexey Melnikov <[email-masked]> wrote:
> 
> > 5.3.  PBKDF2
> >

NIST currently says at least 10,000 and everyone copied it from them. It was changed from 1,000 in 2000 to 10,000 in 2016 (https://web.archive.org/web/20160624033024/https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-verifiers).

---

From: "Sam Whited" <[email-masked]>
Date: Wed, 04 Nov 2020 08:09:46 -0500

On Tue, Nov 3, 2020, at 09:56, Alexey Melnikov wrote:
> a server SCRAM implementation? 

Yes, thanks, I've earmarked this for an update to be clear about how you apply a pepper. In KDFs that don't handle salts themselves, appending the pepper to your own salt is enough. In KDFs that automatically create a salt, you'd want to append it to the password. Basically use peppers exactly the same way you'd use a salt.

> SCRAM-SHA-512 draft to match).

I took it from OWASP (https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2), I believe NIST uses the same number.

—Sam

---

From: "Sam Whited" <[email-masked]>
Date: Wed, 04 Nov 2020 08:51:17 -0500

Actually, I'll just mention that it gets appended to the password. Since
the salt isn't secret (and some algorithms append it to the output hash
in plaintext), you should never append your pepper to your salt. Let's
not mix secrets with things that aren't secret and might be leaked.

—Sam

On Wed, Nov 4, 2020, at 08:09, Sam Whited wrote:
> Yes, thanks, I've earmarked this for an update to be clear about how
> you apply a pepper. In KDFs that don't handle salts themselves,
> appending the pepper to your own salt is enough. In KDFs that
> automatically create a salt, you'd want to append it to the password.
> Basically use peppers exactly the same way you'd use a salt.

---

From: Kim Alvefur <[email-masked]>
Date: Wed, 4 Nov 2020 15:39:45 +0100

On Wed, Nov 04, 2020 at 08:09:46AM -0500, Sam Whited wrote:
> > Can you describe in more details what the last quoted sentence means
> > for a server SCRAM implementation?
>

On Wed, Nov 04, 2020 at 08:51:17AM -0500, Sam Whited wrote:
> Actually, I'll just mention that it gets appended to the password.
> Since the salt isn't secret (and some algorithms append it to the
> output hash in plaintext), you should never append your pepper to your
> salt. Let's not mix secrets with things that aren't secret and might
> be leaked.

I don't see how pepper makes sense in SCRAM. There is no slot for it in
the protocol and the bits that go into the key derivation function must
be known by the client as well as the server, so I don't see how it can
be kept a secret.

-- 
Regards,
Kim "Zash" Alvefur

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 4 Nov 2020 14:43:53 +0000

> be known by the client as well as the server, so I don't see how it can

Right. If it is combined with salt, SCRAM client needs to be notified of 
the combined value.

---

From: "Sam Whited" <[email-masked]>
Date: Wed, 04 Nov 2020 11:25:32 -0500

I'll clarify that as well; you're right that it doesn't make sense with
SCRAM, only for eg. PLAIN with a strong KDF used on the server.

Note that this along with the lack of agility is one of the reasons I'm
always hesitant to recommend SCRAM to people. This is something I'd be
curious to get this groups take on: I generally think that a MITM is not
likely how your password will be stolen, therefore SCRAM is of little
value since it makes agility harder in case a weakness is discovered in
the KDF or the implementation, it makes it harder to use a pepper
(though peppers are arguably of limited value too), etc. Figuring out
that balancing act is tough though, and I'm not sure which is more or
less likely to result in compromise in a real world attack.

—Sam

On Wed, Nov 4, 2020, at 09:39, Kim Alvefur wrote:
> > > Can you describe in more details what the last quoted sentence
> > > means for a server SCRAM implementation?
> >
> > Yes, thanks, I've earmarked this for an update to be clear about
> > how you apply a pepper. In KDFs that don't handle salts
> > themselves, appending the pepper to your own salt is enough. In
> > KDFs that automatically create a salt, you'd want to append it to
> > the password. Basically use peppers exactly the same way you'd use
> > a salt.
>
> > output hash in plaintext), you should never append your pepper to
> > your salt. Let's not mix secrets with things that aren't secret and
> > might be leaked.
>
> I don't see how pepper makes sense in SCRAM. There is no slot for it
> in the protocol and the bits that go into the key derivation function
> must be known by the client as well as the server, so I don't see how
> it can be kept a secret.
>
> --
> Regards, Kim "Zash" Alvefur
>
> Attachments:
> * signature.asc

-- 
Sam Whited

---

From: "Jim Fenton" <[email-masked]>
Date: Wed, 04 Nov 2020 11:58:13 -0800

On 3 Nov 2020, at 16:54, [email-masked] wrote:

>>>     |          Parameter          | 
>>> Value               |
> NIST currently says at least 10,000 and everyone copied it from them. 
> It was changed from 1,000 in 2000 to 10,000 in 2016 
> (https://web.archive.org/web/20160624033024/https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-verifiers).

It would be better to find a way not to specify the work factors at all, 
since they change as processors get faster and RFCs are never revised. 
On the other hand, NIST Special Publication 800-63 is revised from time 
to time, and is currently in the early stages of its next revision. 
It’s too early to know whether that iteration count will be increased.

-Jim

---

From: [email-masked]
Date: Wed, 4 Nov 2020 15:40:18 -0600 (CST)

> On 11/04/2020 1:58 PM Jim Fenton <[email-masked]> wrote:
> 
>  

There is, see "[kitten] Password KDF settings on draft-ietf-kitten-password-storage-01". Basically you limit the attacker's speed to at most 10 kH/s/GPU. GPU is a current high end GPU running whatever software runs the fastest. That's currently RTX 3080 and Hashcat.

> It’s too early to know whether that iteration count will be increased.

Note that when CUDA (2007) and OpenCL (2009) came out it 10x the speed of password cracking. So ignoring any speed ups in computing since 2000 we should be at 10,000 iterations just because GPUs exist. Long story short, minimums for <10 kH/s on an RTX 3080:

PBKDF2-HMAC-SHA1:   720,000
PBKDF2-HMAC-SHA256: 310,000
PBKDF2-HMAC-SHA512: 120,000

P.S. Here's a brief history of which GPU is the one you should benchmark against and when it came out:
R9 290X:        October 24, 2013
* Somewhere around here Nvidia's GPUs became better than AMD's *
GTX 980:        September 18, 2014
GTX 980 Ti:     June 1, 2015
GTX 1080:       May 27, 2016
GTX 1080 Ti:    March 5, 2017
RTX 2080:       September 20, 2018
RTX 2080 Super: July 23, 2019
RTX 3080:       September 17, 2020

I think there was a year where the new card was worse than the old card due to thermal throttling. I think it was the successor of the R9 290X in June 2015, R9 Fury X. Maybe in 2014 it was still the R9 290X.