idnits 2.17.00 (12 Aug 2021) /tmp/idnits63494/draft-kistel-encrypted-password-storage-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 7, 2013) is 3087 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Kisteleki 3 Internet-Draft RIPE NCC 4 Intended status: Informational December 7, 2013 5 Expires: June 10, 2014 7 Password Storage Using Public Key Encryption 8 draft-kistel-encrypted-password-storage-00 10 Abstract 12 Current password storage methods predominantly use cryptographic hash 13 functions in order to avoid storing users' passwords in clear text. 14 Unfortunately, recent advancements in hardware design (notably GPUs) 15 allow an attacker to try millions or even billions of password 16 guesses per second which makes "decryption" of simple passwords 17 feasible in short amounts of time. 19 This document describes a password storage scheme that incorporates 20 public key encryption in order to slow down password verification. 21 Since public key algorithms are several orders of magnitude slower 22 than hash functions, the result makes it much harder for an attacker 23 to discover users' passwords from the stored, encrypted format. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 10, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Problem Description . . . . . . . . . . . . . . . . . . . 2 61 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Algorithm Description . . . . . . . . . . . . . . . . . . . . 3 63 3. Algorithm Properties . . . . . . . . . . . . . . . . . . . . 4 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 1.1. Problem Description 73 The vast majority of information services use usernames and passwords 74 in order to authenticate users of the service. Instead of storing 75 these passwords in clear text form, the best current practice 76 involves adding some entropy ("salt") to the password, 77 cryptographically hashing the result, and storing the resulting 78 value, as well as the input salt, in the password database. 80 If an attacker gets hold of this database (via breaking into a system 81 and copying the password database, or using an application bug to 82 reveal it in some other way), they can apply massive amounts of 83 offline CPU/GPU power, use rainbow tables, etc. to find out the 84 original passwords. Modern hardware can be used to apply brute force 85 and execute staggering amounts of password tries in short amounts of 86 time. One can also use precomputed values (rainbow tables) to speed 87 up the process even further. 89 One of the reasons for why this can be successful is that the hashing 90 algorithm can be implemented in hardware -- one can do millions- 91 billions of password tries per second on a current GPU. Current 92 practices (for example PKBDF2 [PKBDF2]) try to address this by 93 applying multiple rounds of hashing in order to slow down this 94 mechanism. But in practice the number of rounds is mostly set to a 95 default of 100 or 1000 or such, so precomputing tables is still 96 feasible. 98 One solution to this problem is to incorporate a "known slow", one 99 way algorithm into the mix, thereby making it more difficult for an 100 attacker to do large amount of tries too quickly. Preferably the 101 algorithm should have no generally and cheaply available hardware 102 implementation. Also, it should be a generally known and widely 103 implemented algorithm. For example, RSA public key encryption could 104 be used. 106 1.2. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. Algorithm Description 114 The proposed method stores user passwords as follows: 116 1. Pick a suitable hash function (e.g. SHA-256) and public key size 117 (e.g. 2048 bits). 119 2. Generate a public-private key pair, but keep only the public key 120 part and destroy the private key immediately. 122 3. In order to store a password, create the hash over the 123 concatenation of the salt and the password, then encrypt it with 124 the public key generated above. The result is hashed again, 125 which results in a limited size output. The pseudocode for the 126 storage algorithm is therefore: 128 output = hash( rsa_encrypt( hash( salt+password ), public_key ) ) 130 4. When verifying the password, the same algorithm is applied to the 131 input; then the result is compared with the stored value as 132 usual. 134 During the encryption step, OAEP or PKCS1 v1.5 padding cannot be used 135 because they are not deterministic in terms of output, which means 136 comparison of stored vs. recomputed would be impossible. Therefore 137 the RSA encryption should be applied without using a padding scheme. 138 The salted hash given as the input to the RSA encryption provides 139 sufficient randomness for this particular purpose. 141 3. Algorithm Properties 143 It is reasonable to assume that if an attacker gets hold of the 144 password file, they will also obtain a copy of the corresponding 145 public key. In this case, every password guess attempt still 146 requires an RSA encryption operation, which makes it considerably 147 slower to compute passwords using a brute force approach. 149 It is believed to be computationally infeasible to reveal passwords 150 in case of an attacker getting hold of the password file but not the 151 public key. 153 The key space provided by asymmetric algorithm used makes it 154 infeasible to maintain and use rainbow tables for the decryption of 155 the passwords (the same password and salt results in a different 156 encoded form because the use of different public keys). 158 Use of this method also slows down the password verification for the 159 regular login use case; the size of the asymmetric key used affects 160 the performance of both the benevolent and rogue use cases. It is 161 therefore RECOMMENDED for the operator to choose the key size based 162 on the expected and peak password verification (login) rate. Even 163 small key sizes can introduce significant complexity for an attacker 164 while not affecting the regular password verification times too much. 166 The operator MAY choose to use multiple public keys at the same time. 167 For example, the operator can choose to use a new key of the same -- 168 or even different -- size from a certain point in time for storage of 169 newly created passwords, while older passwords can still be verified 170 using the previous key material. As long as all the used public keys 171 used are accessible to the operator, this makes is possible to 172 migrate passwords to be encrypted by the new key over time. 174 In addition to the algorithm description and salt used, each stored 175 encrypted password SHOULD be accompanied by a reference to the public 176 key used during the encryption process. For example, using the "$" 177 character as the delimiter the format can be: 179 $$$ 181 4. Security Considerations 183 If the public key used to encrypt the passwords is no longer 184 available, then no passwords can be verified any more. Therefore the 185 operator MUST ensure that the public key used in this method is 186 available at all times. 188 The private part of the used RSA key SHOULD be destroyed immediately 189 after generation. 191 5. Acknowledgements 193 The author would like to thank Richard Barnes and Stephen Kent for 194 their feedback during the preparation of this draft. 196 6. Normative References 198 [PKBDF2] Wikipedia, "PBKDF2", 2013, 199 . 201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", BCP 14, RFC 2119, March 1997. 204 Author's Address 206 Robert Kisteleki 207 RIPE NCC 208 Amsterdam 209 NL 211 Email: robert@ripe.net