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

[Simon Josefsson <[e-mail]>]

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.

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

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?

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.

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.

/Simon