Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06

[Simon Josefsson <[e-mail]>]

mån 2016-10-10 klockan 08:58 -0700 skrev Dan Harkins:
>    Hello,
> 
> On 10/10/16 12:18 AM, Simon Josefsson wrote:
> > mån 2016-10-10 klockan 09:03 +0200 skrev Stefan Winter:
> >> Hello,
> >>
> >>> I still believe it is a bad idea to describe non-iterative password
> >>> protection schemes at all.  We have had 15+ years of bad incidents with
> >>> salted password databases that suggest it is time to stop doing that.
> >> This is not the ocean this draft attempts to boil.
> >>
> >> The draft does not make any recommendations about how to store passwords.
> > Hello Stefan.
> >
> > Recommendations ought to be part of the security considerations.  It
> > already is part of the document, to some extent.
> >
> >> It attempts to make password databases usable with a new EAP type.
> >>
> >> I don't think you are actually stating that salt-hash databases don't
> >> exist in massive amounts in deployed reality? Because saying so would be
> >> quite silly; they do exist.
> > Of course.  I did not say that, and if you got that impression, I must
> > have been terribly unclear in what I wrote.
> >
> > I question whether deployed PRECIS/OpaqueString databases prepared
> > passwords salted+hashed with SHA1 exists.  PRECIS/OpaqueString is fairly
> > new.  My perception is that people who are knowledgeable enough to use
> > PRECIS/OpaqueString to prepare passwords in general also know that
> > salting passwords is not sufficient.
> 
>    But the draft doesn't specify OpaqueString with SHA1.

It used to, I see now that you removed it.  Thank you!  There is still
salt+SHA256 and salt+SHA512 though.  Are they there for legacy reasons?
I think the draft ought to be clear on which algorithms are for legacy
reasons and which ones are recommended for security.  OpaqueString
+PBKDF2 and OpaqueString+scrypt reflect two reasonable choices these
days.  The others are for legacy reasons.

> >> If we were to ignore that deployed reality and spec the draft merely
> >> around PBKDF2 and some, we'd have an EAP type supporting only a tiny
> >> fraction of password databases out there. All the rest of deployed
> >> reality is left without a good zero-knowledge EAP type and is remains
> >> stranded with "traditional" PKIX-style server validations with either a
> >> cleartext password or a lousy NT-Hash inside the TLS tunnel - which, as
> >> our experience in a world-scale EAP-based roaming consortium shows,
> >> means: no protection at all for many because end users ignore all
> >> certificate warnings given half a chance to.
> >>
> >> It is actually quite easy to improve security for virtually everybody
> >> using EAP: it's these few paragraphs in the draft which describe how to
> >> use salted databases.
> > I'm with you on the high-level discussion.  So let's discuss details.
> > My assertions are:
> >
> > 1) Drafts dealing with password hashing should not ignore security
> > practices around password hashing.  Supporting PBKDF2 is a hygiene
> > factor, scrypt gives bonus points.
> 
> It does support PBKDF2 now. Yes, it does so under the guise of scrypt
> because the scrypt RFC indicates that as an option. Adding support for
> the other scrypt options would open up this draft to ugly negotiation.

I don't understand.  PBKDF2 and scrypt or two completely different
algorithms.  Yes, scrypt uses PBKDF2 internally, but that does not imply
that scrypt offer a PBKDF2 fallback variant.

> I can get away with crypt() doing a myriad of stuff under the covers
> because it embeds the specific algorithm in the salt and all I need
> to do is say do crypt().
> 
>    So does this draft not already pass the hygiene test and also get
> a single bonus point?

Unless I'm missing something, you need to separate scrypt from PBKDF2.
They aren't compatible.

> > 2) Complexity leads to reduced security.  Is there legacy justification
> > for all variants of hashes specified in the document?  Is there legacy
> > justification for both SASLprep and PRECIS/OpaqueString?
> 
>    I believe the answer to the first question is yes. That is the motivation
> for this draft. Regarding the second question, there is no legacy
> justification for OpaqueString but there is one for SASLprep, that's
> whey there's an option for SASLprep with SHA-1 but none for OpaqueString
> with SHA-1.

Okay thanks for clarifying!  Are there deployed databases that uses
SASLprep and salt+SHA256 and salt+SHA512 respectively?

My point here is that by having them in the draft, there is a risk that
people will chose it even in new deployments "just because it works".
If there is no deployed base, let's not give people rope to hang
themselves.

> > 3) I challenge that PRECIS/OpaqueString-prepared passwords are deployed
> > in a salted+hashed way but without iterative constructs.  If you have
> > pointers to the opposite, for each of the specified hashes, I'm happy to
> > learn something new.
> 
>    I have no pointers but if that is your challenge that you should be
> happy that the draft supports OpaqueString-prepared passwords with
> SHA-256 and SHA-512-- i.e. no iterative constructs.

No, I would be happy with this case:

1) PRECIS/OpaqueString is specified for PBKDF2 and/or scrypt only.

I would be okay with:

2) A pointer to some existing deployed legacy database that uses
OpaqueString+salt+SHA256/512.

A situation where the draft specify OpaqueString+salt+SHA256/512 without
any proven legacy need for it is not okay in my mind.

>  It also supports
> OpaqueString-prepared passwords with scrypt/PBKDF2 with SHA-256 and SHA-512
> so we should have all bases covered.

Right now the scrypt/PBKDF2 variant looks confused to me.  They are two
different algorithms.  Scrypt does not allow you to chose the hash.
PBKDF2 allows the choice, but then you should cite RFC 2898.

> > What do you think?
> >
> > I'm aware of password databases that use raw salt+hash on (unprepared)
> > UTF-8 encoded password strings.  In my experience, that is more common
> > than salt+hash of SASLprep or PRECIS/OpaqueString passwords.  The draft
> > does not discuss how the password is encoded for TBD1-TBD10, which seems
> > like another missing piece.
> 
> It says:
>    When using SASLprep a password SHALL be considered a "stored string" per
>    [RFC3454] and unassigned code points are therefore prohibited. The
>    output of SASLprep SHALL be the binary representation of the
>    processed UTF-8 character string.  Prohibted output and unassigned
>    codepoints encountered in SASLprep pre-processing SHALL cause a
>    failure of pre-processing, and the output SHALL NOT be used with EAP-pwd.
> 
> For the non-internationalized EAP-pwd already says:
>    The input password string SHALL be treated as an ASCII
>    string or a hexadecimal string with no treatment or normalization
>    performed.  The output SHALL be the binary representation of the
>    input string.
> 
>    I'm really not sure what changes are still needed in this draft. If
> there are, please tell me again.

Exactly.  So if you re-read what I wrote, my point is that my perception
is that salt+hash'ed UTF8 passwords is not uncommon, and the draft does
not describe that variant.

/Simon