Re: [secdir] secdir review of draft-ietf-httpauth-basicauth-update-06

[Julian Reschke <[e-mail]>]

On 2015-02-19 19:22, Daniel Kahn Gillmor wrote:> ...
 > I don't have the bandwidth to craft something fancy right now, but
 > here's a first stab that you're welcome to carve up as you see fit, if
 > no IETF references are forthcoming:
 >
 >     Servers and proxies requiring Basic Authentication must store user
 >     passwords in some form in order to verify the request's
 >     Authorization: header.  These passwords should be stored in such a
 >     way that a leak of the password table doesn't make them trivially
 >     recoverable.  This is especially when users are allowed to set their
 >     own passwords, since users are known to choose weak passwords and to
 >     reuse them across authentication realms.  While a full discussion of
 >     good password hashing techniques for HTTP Basic Authentication is
 >     beyond the scope of this document, server operators should make an
 >     effort to minimize risks to their users in the event of a password
 >     table leak.  For example, servers should not store user passwords in
 >     plaintext or as unsalted digests.  For more discussion about modern
 >     password hashing techniques, see [PHC].
 >
 >   [PHC] https://password-hashing.net Password Hashing Competition
 >
 > (i've used "should not" instead of RFC 2119 "SHOULD NOT" above because
 > this is not a recommendation about the on-the-wire protocol.  If anyone
 > thinks it should be elevated to an RFC 2119 "SHOULD NOT" i'd be happy to
 > see that happen, because this is seriously low-hanging fruit, and i'm
 > sure there are still operators out there disregarding it.
 > ...

I have added very similar text with 
<http://trac.tools.ietf.org/wg/httpauth/trac/changeset/125>):

 >>    Servers and proxies implementing Basic Authentication need to store
 >>    user passwords in some form in order to authenticate a request.
 >>    These passwords ought to be be stored in such a way that a leak of
 >>    the password data doesn't make them trivially recoverable.  This is
 >>    especially important when users are allowed to set their own
 >>    passwords, since users are known to choose weak passwords and to
 >>    reuse them across authentication realms.  While a full discussion of
 >>    good password hashing techniques is beyond the scope of this
 >>    document, server operators ought to make an effort to minimize risks
 >>    to their users in the event of a password data leak.  For example,
 >>    servers ought to avoid storing user passwords in plaintext or as
 >>    unsalted digests.  For more discussion about modern password hashing
 >>    techniques, see the "Password Hashing Competition"
 >>    (<https://password-hashing.net>).

Thanks for the proposal!

Best regards, Julian