Subject: [kitten] I-D: Best practices for password hashing and storage

From: "Sam Whited" <[email-masked]>
Date: Mon, 27 Apr 2020 09:31:52 -0400

Hi all,

I've been working on a document making recommendations for password
hashing and storage (possibly with a focus on SASL). I was encouraged to
turn it into an I-D and ask if it was something the KITTEN WG would be
interested in? If so, what would the process look like going forward?

The initial draft has been uploaded here:
https://datatracker.ietf.org/doc/draft-whited-kitten-password-storage/

As an I-D the scope of the document is potentially much broader than the
one I was originally writing, so suggestions for anything else that
might be useful to include would be welcome. For example, adding a
section on how to properly tune KDFs for your service might be a good
future addition.

—Sam

-- 
Sam Whited

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 29 Apr 2020 00:43:20 +0200

Hi,

Nice work!  Some minor comments:

  1) I consider PLAIN worse than DIGEST/CRAM-MD5.  Maybe it will help
  the reader understand better if you explain the criteria for sorting.

  2) By describing how implementations should handle credentials for
  PLAIN, it encourages continued use of PLAIN.  PLAIN is a bad idea from
  many perspectives.  I believe that it is better to say that if any
  work to improve security is done on a client or server that uses
  PLAIN, it should be to move to SCRAM-SHA-256, not to implement various
  mitigations.  Mitigations prolongs the transition pain and deter focus
  from the process of moving away from PLAIN.

/Simon

---

From: "Sam Whited" <[email-masked]>
Date: Tue, 28 Apr 2020 23:20:28 -0400

>      the reader understand better if you explain the criteria for

Good idea, thank you. I've submitted a new draft explaining why I
ordered them the way I did, and some caveats about each individual
mechanism.

In the case of PLAIN vs DIGEST auth I've given PLAIN a higher perceived
strength because DIGEST-MD5 forces you to store the password on the
server using a weak hash. With PLAIN it may not have any protection over
the wire (not that DIGEST-MD5 really gives you any at this point
either), but on the back end you can hash it however you want.

Also note that DIGEST-MD5 is forbidden by this document and the
example that mentions it specifically says that it's not endorsing
using it, just giving an example of how it would be ranked so I think
it's okay. That being said, maybe it's worth not mentioning DIGEST/CRAM-
MD5 at all.

>      PLAIN, it encourages continued use of PLAIN.  PLAIN is a bad idea
>      from many perspectives.  I believe that it is better to say that
>      if any work to improve security is done on a client or server
>      that uses PLAIN, it should be to move to SCRAM-SHA-256, not to
>      implement various mitigations.  Mitigations prolongs the
>      transition pain and deter focus from the process of moving away
>      from PLAIN.

PLAIN makes the hash used to store the passwords more agile, which is
the main weakness of SCRAM (in my very amateur opinion that should
likely be taken with a grain of salt until this has all had expert
review). If I'm using SCRAM-SHA-1 and a preimage attack is found for SHA
1, for example and I want my users to upgrade to SCRAM-SHA- 2, I may
have to convince both clients and servers to support the new mechanism.
This is fine in proprietary systems where the client and servers are
under the control of the same entity, but isn't fine for systems like
XMPP, for example, where changing SCRAM versions could cause
incompatibilities between some clients and servers. Of course, a SHA1
preimage attack may not be likely, but it's just an extreme example of
what can go wrong when you don't have hash agility.

Also, when integrating with other systems (eg. an existing HTTP system
that uses bcrypt to hash passwords) you're stuck using something like
PLAIN since with SCRAM you'd have to store two separate hashes (your
applications legacy bcrypt one and the PBKDF2 hashed one).

I'm also for encouraging SCRAM usage, I just think it's worth proceeding
with caution because PLAIN may actually be a better fit for some systems
depending on your compatibility and security requirements. If people are
already using it (and they are), it might be more beneficial to tell
them how to do it as safely as possible instead of leaving them hanging.

—Sam

-- 
Sam Whited

---

From: Robbie Harwood <[email-masked]>
Date: Wed, 29 Apr 2020 12:15:38 -0400

"Sam Whited" <[email-masked]> writes:

> hashing and storage (possibly with a focus on SASL). I was encouraged
> to turn it into an I-D and ask if it was something the KITTEN WG would
> be interested in? If so, what would the process look like going
> forward?
>
> As an I-D the scope of the document is potentially much broader than
> the one I was originally writing, so suggestions for anything else
> that might be useful to include would be welcome. For example, adding
> a section on how to properly tune KDFs for your service might be a
> good future addition.

Hi Sam, with my chair hat on:

In order for adoption to occur, I'd like to see expressed interest from
multiple folks in the WG (and a formal call for adoption).  This may
mean it sits a bit longer / has more revisions as an individual I-D,
which is fine.  I don't think we're over capacity, so taking on more
work here should be possible if we have consensus to do so.

Happy to answer other process questions as best I can.

Thanks,
--Robbie

---

From: "Sam Whited" <[email-masked]>
Date: Wed, 29 Apr 2020 17:37:06 -0400

On Wed, Apr 29, 2020, at 12:15, Robbie Harwood wrote:
> In order for adoption to occur, I'd like to see expressed interest
> from multiple folks in the WG (and a formal call for adoption).

That sounds good; how does that normally happen? Should I start hounding
people, or is this email sufficient? (/cc Dave Cridland who I think is
involved and who encouraged me to submit this I-D).

Many thanks.

—Sam

-- 
Sam Whited

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 29 Apr 2020 20:14:15 -0700

> involved and who encouraged me to submit this I-D).

I would probably give the original mail a week or so bake time and see what
response it elicits before going out of your way to get further review.
That said, if you know of people who would be interested but are not on
this list, by all means invite them to comment here.

-Ben

---

From: Dave Cridland <[email-masked]>
Date: Thu, 30 Apr 2020 11:51:30 +0100

A tiny bit of background:

https://xmpp.org/extensions/inbox/password-storage.html was submitted to
the XMPP Standards Foundation [think somewhere between an I-D publication
and a WG adoption request], and while the Council [WG chair/IESG] is happy
to accept it, pretty much everyone seems to agree that if this can go
through IETF/KITTEN instead, it'll be a better document for it.

But everything else that's taken this route has sunk without trace, so
we're likely to publish the XEP (as Experimental - akin to WG I-D) anyway,
and then we can retract it if it actually does take root here. At least on
my part, this is an intentional policy change to ensure that the document
is reviewed and published *somewhere*. Previously I have tended to block
these kinds of documents and force them to the IETF (and KITTEN). As a
result we have (for example) multiple SASL mechanism proposals
effectively dead in the water, and so expediency somewhat forces this
dual-publication approach.

There are a number of people interested in this document in the XSF, but
previous attempts having failed, we will have to spend some effort to
encourage people from the XSF to come here and participate. I personally
think that would be effort well-spent.

Thanks,

Dave.

On Thu, 30 Apr 2020 at 04:14, Benjamin Kaduk <[email-masked]> wrote:

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>