Network Working Group S.M. Bellovin
Internet-Draft Columbia University
Intended status: Standards Track March 2012
Expires: August 31, 2012

Hashed Password Exchange
draft-bellovin-hpw-01.txt

Abstract

Many systems (e.g., cryptographic protocols relying on symmetric cryptography) require that plaintext passwords be stored. Given how often people reuse passwords on different systems, this poses a very serious risk if a single machine is compromised. We propose a scheme to derive passwords limited to a single machine from a typed password, and explain how a protocol definition can specify this scheme.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 31, 2012.

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction

Today, despite the lessons of more than 30 years [[cite Morris and Thomson]], many systems store plaintext passwords. This is often done for good reasons, such as authenticating some cryptographic exchanges or as a convenience to users with many passwords; see, for example, the password store in many browsers or the Keychain in MacOS. That said, this practice does pose a security risk to users, since their passwords are in danger if the system is compromised.

The big problem is not compromise of the actual password used on that system; while regrettable, it is inherent in the service definition. Rather, the problem is that users tend to reuse passwords on different systems. If a password is compromised on one machine, the user is at risk on many different systems. Accordingly, we describe a scheme for storing a single-site-only password, derived from the user's typed password; a compromise of a service thus affects just that service.

To accomplish this, we specify a "Hashed Password Exchange" standard, or rather, a metastandard. Rather than specifying a precise way to store and use hashed passwords, we give rules for specifying hashed passwords for use in a given protocol or application. We take advantage of the fact that unlike 1979, when users used very dumb terminals to transmit passwords directly to the receiving applications, most passwords these days are entered into user-controlled software; these programs in turn transmit the passwords to the verifying applications. There is thus intelligence on the user's side; we will use this to irreversibly transform the entered password into some other string. By the same token, the receiving system must apply the same transform to the authenticator supplied at user enrollment time or password change time. Because two independent pieces of software must apply the same transformation, the algorithm must be precisely specified in standards documents.

Note that defeating guessing attacks on a captured password file is not the primary goal of this work. That goal, though laudable, ignores changes in technology and environment since the Morris and Thompson paper; today, far more passwords are lost to keystroke loggers, phishing attacks, direct compromise of the server itself, or (as was a problem even 30+ years ago) online guessing attacks. Our scheme helps against this last attack, in that generation of the guesses becomes more expensive; against the other threats, password strength is completely irrelevant. We also note that today, people have very many different passwords. It is impossible to remember large numbers of strong passwords; absent use of a password generator and manager, there *will* be reuse across different services.

1.1. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Definitions and Goals

We use the following definitions:

Username
An arbitrary string, the syntax of which is application-dependent, employed by both the user and the verifying system to uniquely identify a given user.
Entered Password
The authenticator typed by the user to his or her own software. The usual quality rules (length, special characters, etc.) can be applied; that is out of the scope of this standard.
Effective Password
The actual, over-the-wire, string transmitted by the user's software.
Service
A particular application on a particular machine or cluster of machines appearing as a single machine
Hostname
The hostname as supplied by the user.
Service URI
A URI [RFC3986] for which this effective password should be valid. Only the scheme name, userinfo, and host name portions are discussed here; use of path information is protocol-dependent. In the userinfo field, only the username is used. An example is given below.

Our scheme has the following goals:

  1. No two users of a given service should have the same effecive password, even if the entered passwords are the same.
  2. No two effective passwords for the same user should be the same for different services, even if the entered passwords are the same.
  3. It should be infeasible to invert the hashing function to retrieve the entered password from an effective password and service URI.
  4. It should be computationally expensive to mount dictionary attacks on compromised effective passwords.

3. The Hashed Password Scheme

Fundamentally, we calculate the effective password by iterating HMAC [RFC2104], using the entered password as the key and the service URI as the data. This meets all four of our goals:

  1. Since the username is part of the service URI, different users will have different URIs, and hence different effective passwords.
  2. Since the hostname is part of the URI, different services for any given user will have different URIs, and hence different effective passwords.
  3. For any reasonable underlying hash function, it is believed to be infeasible to invert HMAC; see [RFC2104] for details. (Arguably, HMAC is overkill. Nevertheless, it is a well-studied, well-understood mechanism for combining known plaintext with a secret key. We see little benefit to concocting some other scheme.)
  4. By iterating a sufficient number of times, dictionary attacks can be made arbitrarily expensive. (Although guessing attacks can be made arbitrarily cheap today by use of cloud services or botnets, we prefer to look at it somewhat differently. Whatever the resources the attacker has, his or her effective guessing rate is cut by a factor of the iteration count.)

We do not use a salt in this scheme. The primary purposes of a salt are to achieve our first and second goals, which we achieve in other ways. A salt also protects against precomputation of possible passwords of known users in anticipation of a later password file compromise. Our use of service-, host-, and user-specific hashed passwords provides the same protection against untargeted guessing attacks; furthermore, and as noted, guessing attacks are not the primary threat today. Since the salt must be used in calculating the effective password, it would have to be known to the user as well as the server, and users typically have multiple devices on which they enter passwords. Using a salt would require that users know it and reenter it, which we regard as of limited benefit and highly user-hostile: people will *not* tolerate copying random strings or numbers onto multiple platforms, especially phones and the like.

Usernames and the hostname portions of service URIs must be canonicalized before applying HMAC. Legal characters in a username are upper and lower case US-ASCII letters, period, hyphen, underscore, and digits. All other characters MUST be percent-encoded, per section 2.1 of [RFC3986]. Hostnames MUST be canonicalized per [RFC5890][RFC5891] and converted to lower case. How usernames and hostnames are entered is application- and implementation-dependent, and not part of this specification. The hostname used is either the string users type or unambiguously derivable from it per specified rules.

The URI scheme name is given by the protocol specification and MUST NOT be entered directly by the user.

The iteration count is protocol- and use-dependent, and given in the protocol specification.

The effective password, then, is calculated by iterating HMAC some number of times over the message

with the entered password as the key.

3.1. Examples

Note that although someuser can specify the same entered password for both 'imap' and 'submission' on mail.example.com, the effective passwords will be different.

4. Specifying Hashed Password Exchange

The following elements must be in any protocol specification that uses Hashed Password Exchange.

How passwords are changed -- that is, how new effective passwords are supplied to the verifying machine -- is beyond the scope of this specification. If the entered password is sent directly at password change time, quality checks can be enforced; however, this exposes entered passwords to attacks who have compromised the verifying machine. This is not a major risk, since the rate of password change is low. Conversely, client-side code (e.g., Javascript) can make advisory recommendations on password strength; while the server cannot enforce this, since it will see only effective passwords, very few users will have the will and the skill to override this.

If effective passwords are used only for the usual password verification and not for cryptographic purposes, they should be treated with the care used for ordinary password, i.e., read-protected, hashed, etc. There is little need for extra iterations, though, since the iteration used in calculating them already provides strong protection against dictionary attacks, and it is unlikely that the extra server-side iterations will be significantly larger than the iterations already performed to comply with this specification. As before, there is no need for an additional salt.

5. Related Work

A number of papers have described schemes for browser-based password stores that simplify the process of having separate effective passwords for different web sites. Many -- [[Abadi--pwdhash]] [[Halderman et al.]] -- use a cryptographic function of the domain name and a master password to calculate it. [[Abadi-pwdhash]] has many pointers.

This work differs in two important ways. First, it applies to more services than just HTTP. Second, it specifies how other protocol specification documents should handle the situation, independent of requirements for password strength.

6. Acknowledgments

A number of people made useful comments and suggestions, even if they didn't agree with all parts of this document. They include Martin Abadi, Uri Blumenthal, Dan Harkins, Mouse, Yaron Sheffer, Joe Touch, and Sujing Zhou.

7. Security Considerations

To be written.

8. References

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC6124] Sheffer, Y., Zorn, G., Tschofenig, H. and S. Fluhrer, "An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol", RFC 6124, February 2011.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.

Appendix A. Change History

Appendix A.1. Changes from -00 to -01

Appendix B. Open Issues

Author's Address

S.M. Bellovin Columbia University 1214 Amsterdam Avenue MC 0401 New York, NY 10027 US Phone: +1 212 939 7149 EMail: bellovin@acm.org

Table of Contents