Opened 8 years ago

Closed 7 years ago

#3 closed defect (fixed)

A few issues with pwd-hash

Reported by: ynir@… Owned by: draft-ietf-httpauth-mutual@…
Priority: major Milestone:
Component: mutual Version:
Severity: - Keywords: pwd-hash hash legacy MD5
Cc:

Description

Noted by Ilari, Stephen, Yaron

In section 4.1:

pwd-hash: (non-mandatory extensive-token) specifies the hash

algorithm (hereafter referred to by ph) used for
additionally hashing the password. The valid tokens
are

  • none: ph(p) = p
  • md5: ph(p) = MD5(p)
  • digest-md5: ph(p) = MD5(username | ":" | realm |

":" | p), the same value as MD5(A1) for "MD5"
algorithm in [RFC2617].

  • sha1: ph(p) = SHA1(p)

If omitted, the value "none" is assumed. The use of
"none" is recommended.

First, "none" produces an octet string while the others produce a number. Yaron noted that it was weird for hash functions to return numbers, but either way, should be consistent.

Another thing is the use of MD5 and SHA1. Both these algorithms are falling out of favor. If this exists only to support existing salted and non-salted databases of passwords, this should be said (in general, if something is recommended the draft should say why). Also, given that MD5 and SHA1 are falling out of favor, what is the new best practice for protecting passwords in databases?

Change History (4)

comment:1 Changed 8 years ago by nico@…

MD5 and SHA-1 are a kiss of death as far as getting this deployed goes, FYI. At least in many enterprise organizations. Even if the uses of MD5 and SHA-1 here were not susceptible to collision resistance weaknesses in MD5/SHA-1 the mere use of these algorithms is often enough to disqualify *new* protocols.

comment:2 Changed 8 years ago by y.oiwa@…

For first sub-issue, domain confusion between numbers and octet strings are fixed in -01 draft.

comment:3 Changed 8 years ago by y.oiwa@…

For second sub-issue:

  • first clarification: pwd-hash mechanism and the uses of SHA-1 and MD5 is only for legacy migrations, and SHA-256 or SHA-512 is used throughout the main protocol.
  • The interim meeting concluded that we will look for requirements for legacy migration, including MD5/SHA-1 and other hashing algorithms. If we do not see strong requirement for any of those, we will drop pwd-hash mechanisms entirely. If people needs other hashs, on the opposite, we may add or replace MD5/SHA-1 with it.

comment:4 Changed 7 years ago by mlepinski.ietf@…

  • Resolution set to fixed
  • Status changed from new to closed

I am closing this issue. The domain issue appears to be resolved (see Section 11.2 in the latest version of the document).

The latest version of the document also clearly recommends "none"

The working group has not been able to determine whether there is a compelling need for other pwd-hash values other than "none". Inclusion of those values in the experimental draft adds a bit of implementation complexity, but otherwise appears harmless.

Note: See TracTickets for help on using tickets.