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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Sam Whited
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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Simon Josefsson-2
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

"Sam Whited" <[hidden email]> writes:

> 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

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

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Sam Whited
On Tue, Apr 28, 2020, at 18:43, Simon Josefsson wrote:
>   1) I consider PLAIN worse than DIGEST/CRAM-MD5.  Maybe it will help
>      the reader understand better if you explain the criteria for
>      sorting.

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.


>   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.

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Robbie Harwood
In reply to this post by Sam Whited
"Sam Whited" <[hidden email]> writes:

> 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.
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

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

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Sam Whited
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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
On Wed, Apr 29, 2020 at 05:37:06PM -0400, Sam Whited wrote:
> 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).

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Dave Cridland
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 <[hidden email]> wrote:
On Wed, Apr 29, 2020 at 05:37:06PM -0400, Sam Whited wrote:
> 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).

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

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Sam Whited
In reply to this post by Benjamin Kaduk-2
In the interest of keeping this moving, it's been a little over a week
and I've had a bit of review and Dave of course mentioned the initial
reason he suggested this document be brought here. If anyone else has
feedback or opinions on whether this should or should not be taken on by
the WG, I'd love to hear your thoughts.

Otherwise, what are the next steps?

Thanks as always for your help guiding me through this process. I really
appreciate it.

—Sam

On Wed, Apr 29, 2020, at 23:14, Benjamin Kaduk wrote:
> 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.

--
Sam Whited

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Robbie Harwood
"Sam Whited" <[hidden email]> writes:

> In the interest of keeping this moving, it's been a little over a week
> and I've had a bit of review and Dave of course mentioned the initial
> reason he suggested this document be brought here. If anyone else has
> feedback or opinions on whether this should or should not be taken on
> by the WG, I'd love to hear your thoughts.
>
> Otherwise, what are the next steps?
>
> Thanks as always for your help guiding me through this process. I
> really appreciate it.
Thanks for your patience; that delay was longer than I intended.  I've
issued the formal call for adoption; assuming no objections, I'm
inclined to adopt.

Thanks,
--Robbie

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

signature.asc (847 bytes) Download Attachment