n120801
nfoWorks
nfoNote
AuthzN
Password-Independent Keys
AuthzN Essential Principles
|
|
n120801
nfoWorks
nfoNote |
0.02 2017-06-14 20:22 -0700 |
- The latest version is available on the Internet at
<http://nfoWorks.org/notes/2012/08/n120801b.htm>.
- This version was filed at <http://nfoWorks.org/notes/2012/08/n120801c.htm>. Consult that page for the latest status and for the most-recent electronic revision of this page.
1. Introduction
2. Definition of AuthzN
3. Applications
3.1 Direct use of AuthzN keys
3.2 AuthzN-based password strengthening
3.3 AuthzN-equivalent numeric representations
3.4 Creating AuthzN-equivalent character encodings
4. References
1.1 AuthzN keys maximize the protection of user-chosen passwords when they must be entrusted to external parties. AuthzN keys are resistant to discovery, taking into account the general weakness of password-based authentication implementations. Compromise of a single AuthzN key does not compromise any other AuthzN keys, limiting the potential damage.
1.2 There is nothing inventive about AuthzN. These practices are well-known and well-understood. AuthzN simply has a rigorous definition that can be used to qualify a particular level of protective measure.
1.3 Further details on the motivation for AuthzN can be found in the Summary and supporting Considerations.
2.1 An AuthzN key is a string of N bits. Recommended values for N are 128, 160, 256, 384, and 512.
2.2 An AuthzN key is cryptographically-random.
2.3 AuthzN keys chosen by the same entity shall be independent and unique. Each of those keys is the chosen password in at most one situation in which a password is required for authorization.
2.4 When used as if cryptographic hashes, An AuthzN key will have the same number of bits produced by the cryptographic-hash digest algorithm. E.g., N is 128 for MD5, 160 for SHA1, 256 for SHA256, 384 for SHA384, and 512 for SHA512. In this case, the AuthzN key is said to be disguised as the particular kind of digest.
2.5 Cryptographic hashes of AuthzN keys producing N bits are acceptable as AuthzN keys.
2.6 Where user-chosen passwords are authenticated using cryptographic hashes, the AuthzN key encoded as the password shall have the same number of bits as the cryptographic-hash that is derived. Note: This strict condition depends on information that the user who selects the password might not be able to obtain.
2.7 Whatever the method by which privacy of an user-chosen password is assured, it is acceptable for AuthzN-strength keys if there is an encoding of all N-bit binary strings as distinct, enterable password texts that are accepted and distinguished as separate user-chosen passwords.
2.8 For AuthzN keys to be of acceptable strength, N shall not be less than 128. N should not be less than 160. N is defined to be the maximum AuthzN strength.
2.9 H(AuthzN) is the binary Shannon entropy of AuthzN [Entropy]. The difference N - H(AuthzN) shall be negligible. The efficiency of AuthzN is H(AuthzN)/N. The AuthzN are effectively uncompressible. Efficiencies greater than 1 (100%) are not possible. Compressibility is best expressed as (1-efficiency). A compressibility of 1 (100%) occurs when there is no information.
2.10 Note: The effective cryptographic strength of an AuthzN key can be N/2 or fewer bits depending on the exploit that permits its compromise. This occurs because of the disclosure of related information (such as a digital hash), that makes the AuthzN key discoverable by procedures that are much better than guessing. This justifies the preference for generous values of N.
A direct AuthzN usage depends on the full value of the key being accepted and used, with any derivative of it (such as a hash) being acceptable as an AuthzN for the same N. This must be known for AuthzN strength to be claimed.
3.1.1.1 It is rare for user-facing authentication interactions to accept binary data directly. However, an interface might accept binary data in a common encoding, such as hexadecimal or base64 binary. In that case, the AuthzN key is converted directly to one of those forms and supplied during the authentication interaction.
3.1.1.2 Note: This case applies only when the interface that accepts an encoding uses the encoded AuthzN as the submitted password. For cases where it is the encoding that is taken to be the password, see section 3.2.
3.1.2.1 When a password is communicated in binary data, an AuthzN value can be provided directly.
3.1.2.2 Depending on the medium and the format requirements for data, it may be necessary to express the AuthzN value in an expected encoding (e.g., hexadecimal or base64).
3.1.2.3 Note 1: If privacy of the data cannot be assured, the AuthzN value must be assumed to be compromised. It is essential that it never be reused in any other situation, including elsewhere in data. If the AuthzN value is the cryptographic hash of an original AuthzN key, that key may also be compromised.
3.1.2.4 Note 2: It is desirable to be able to detect the replay of an AuthzN values elsewhere in the same or other data. This will depend on the application that verifies such passwords.
3.1.2.5 Note 3: In situations where a password hash would appear "in plain sight" in a non-secret data/document representation, consider storing an AuthzN of appropriate size in place of the password hash. This is valuable when what the password authorizes is easily accessed/compromised without needing the password. There is now no password that can also be compromised.
3.2.1 N-bit cryptographically-random numbers can be used to produce so-called "strong" passwords. Definition 2.7 reflects the maximum N that might be achieved with user-chosen passwords accepted in a given situation. Definition 2.8 and continuing advances in attack on discovered/disclosed password hashes determine whether that AuthzN is of acceptable strength to qualify as an AuthzN key representation.
3.2.2 When an N-bit value is represented in the guise of an user-chosen text-entered password, the resulting data representation has predictable non-random bits in addition to the N being represented. That regularity may weaken the strength of the result. Such a representation is at best as strong as the AuthzN key. The entropy is not changed, but the efficiency will decrease (section 2.9). The resulting predictability may weaken the protection measures in communication and authentication of the key.
3.2.3 When an AuthzN-based password representation is generated, it is the representation that is supplied for authentication. That is the value that should be preserved and managed by the user in the same manner as a direct AuthzN key.
3.2.4 As a practical matter, it can be easier to generate characters of a random password representation directly so long as it has AuthzN strength.
Expressing N-bit binary numerals, including AuthzN values, in different formats available for user-chosen passwords (and vice versa) is governed by the following constraints.
3.3.1 For numerals in base B > 1 having d digits, the number of values expressed in those numerals is the same as for binary numerals having x bits, such that
2x = Bd (1) x = d × ln(B)/ln(2) (2) d = x × ln(2)/ln(B) (3) where ln(y) is the natural logarithm of y,
ceiling(y) is the smallest integer not less than y,
floor(y) is the largest integer not greater than y
3.3.2 For d-digit base-B numerals,
- The number of bits needed to express all of those values is ceiling(d × ln(B)/ln(2)).
- floor(d × ln(B)/ln(2)) is the maximum number of bits for which all binary values are representable in d base-B numerals.
3.3.3 For x-bit binary numerals,
- The number of base-B digits needed to express all of those values is ceiling(x × ln(2)/ln(B)).
- floor(x × ln(2)/ln(B)) is the maximum number of base-B digits for which all base-B values are representable in x-bit binary numerals.
3.4.1 To create random character sequences that have the equivalent strength to an AuthzN key, it is generally sufficient to generate random sequences of d characters, with d = ceiling(N/H), when using the encoded character sets and the corresponding H values in the table below. E.g., Authz160 using decimal digits requires ceiling(160/3.32) = 49 decimal digits; using the Base64encoding character set, the sequence need only be ceiling(160/6) = 27 characters.
3.4.2 When the chosen encoding does not use the same number of bits for each encoded character, the situation is more complicated. Without compensating for the variability of UTF8, for example, it is better to use only those sets of characters having constant efficiency in the commonly-used encodings.
Encoded Characters
# of
codesbits
H% Efficiency ASCII
8859-1 UTF8 UTF16 Decimal digits: 0-9 10 3.32 41.5 41.5 41.5 20.8 Alphabetic letters: A-Z 26 4.70 58.8 58.8 58.8 29.4 Letters and Digits: A-Z a-z 0-9 62 5.95 74.4 74.4 74.4 37.2 Base64encoding: A-Z a-z 0-9 + / 64 6.00 75.0 75.0 75.0 37.5 Printable ASCII Characters, including space 95 6.57 82.1 82.1 82.1 41.1 Printable ISO 8859-1 Characters, including space 189 7.56 - 94.5 82.2* 47.3 Simple Printable Unicode Characters under U+1000** 1238 10.27 - - 83.2* 64.2 All XML non-specials with UTF8 lengths 1 and 2*** 4025 11.97 - - 84.6* 74.8 All having valid UTF8 codes of length 1 and 2 octets 4096 12.0 - - 89.5* 75.0 * UTF8 requires two octets for encoding any of the Unicode characters having code points U+0080 to U+00FFF. The efficiency is the best available with all binary variability being uniformly random as opposed to the distribution of the character choices being uniformly random. Achieving this efficiency, having character sequences that sustain the corresponding entropy, is complicated and requires deeper analysis than provided for these illustrations.
** The simple printable Unicode Characters are the ones used in ISO 8859-1 plus those having code points above U+00FF that are defined and are not intended for composition with other characters. This limitation avoids constructions that are not valid in languages where the characters are enterable from keyboards.
*** XML accepts more of the same range of code points as legitimate characters, whether or not currently defined for Unicode and whether or not there are linguistic limitations on occurrence of combining forms. To avoid complexity of XML limitations on different places the character encoding might occur, this illustration excludes whitespace characters and characters <, &, ', " and ], with use of XML character entities avoided completely.
- [Entropy]
- Entropy (information theory). (article) Wikipedia, 2012-11-30T20:45. Accessed on 2012-11-30 at <http://en.wikipedia.org/wiki/Entropy_(information_theory)>.
- Hamilton, Dennis E.
- AuthzN Essential Principles. nfoWorks nfoNote page n120801c 0.02, December 9, 2012. Accessed at <http://nfoWorks.org/notes/2010/08/n120801c.htm>.
|
created 2012-08-20-13:13 -0700 (pdt) by
orcmid |
