nfoWorks: tools for document interoperability

n120801 nfoWorks nfoNote
AuthzN Password-Independent Keys

nfoWorks>notes>
2012>08>

n120801>
 0.04 2017-04-10 14:09


visits to popular nfoWorks pages

Locations of visitors to nfoWorks

1. Summary
2. Considerations
    2.1 Password Love
    2.2 More Simple than Secure
    2.3 Password Safety Is Not Simple

3. More Information: Bibliography

1. Summary

1.1 There are many situations where a password must be chosen and used.  This is despite password-based security having serious difficulties:

1.2 Where passwords must be chosen and entrusted to the care of another party, AuthzN may be useful.  It is inconvenient.  It is a stop-gap.  AuthzN protects passwords from discovery.  It does nothing to prevent the exploitation of password-protected material held by an unreliable custodian.

1.3 AuthzN is a family of unique derived keys that can be used in place of personally-chosen passwords.  There is no computational means by which a personal password can be determined directly from an AuthzN key.  AuthzN keys are designed to have their recovery from digital hashes be impractical in case hashes are discovered or disclosed somewhere, a common occurrence these days.

1.4 It is required that AuthzN keys not be reused for any other purpose.  Everywhere a password is to be chosen, a fresh AuthzN key must be used.  In the event that an AuthzN key is somehow compromised, the compromise is limited to the one password-protected function where that AuthzN key is used.  Although sensitive information may be exposed, even without compromising the key, there is no wider exploit achievable with the AuthzN key itself becoming known.

1.5 Users that choose AuthzN-compliant derived keys have the added responsibility of keeping track of which AuthzN key is used for  each password-protected function.  That information must be kept private.  There are software tools that simplify this activity.

1.6 Personal management of AuthzN keys provides a layer of mitigation against compromise of the authorizing service when shared passwords are required.  The only need for a memorable user-chosen password is for an user's own protection of an AuthzN key collection.  That personal password or other privacy protection can be closely guarded and can be quite strong.

1.7 This nfoWorks note specifies AuthzN principles.  Specific applications and details of implementations are found separately.  Consult <http://nfoWorks.org/notes/2012/08/n120801b.htm> for the principles and related topics.  Considerations applicable to any password-based protection scheme are below.

2. Considerations

These are the practical considerations that motivate the establishment of AuthzN

Simple password-based security schemes are prevalent.  Since users have little alternative, understanding and limiting the risks is important.

2.1 Password Love

2.1.1 There are many situations where passwords are required as part of authenticating a requester's permission (authorization) to make access or exercise other restricted privileges.  Arranging on-line accounts usually requires user-chosen passwords for future authentication.  Stronger mechanisms for secure authentication and authorization exist.  These are typically not available.  Authentication arrangements requiring user-chosen passwords are not diminishing and alternatives are rare.  

2.1.2 So long as users choose memorable, non-unique passwords, the password itself becomes a prized asset that is vulnerable to discovery, impersonation, and attacks on other places where the same password is used.  When there is no alternative to user-chosen passwords, it is important to mitigate the risks to discovery of such convenient but vulnerable possessions.

2.1.3 To preserve password confidentiality it is undesirable for a password to be retained anywhere that it might be discovered and misused.   Ideally, the password is not held onto by anyone but the individual that chose it.  Unfortunately, it is usually not possible for the user to know what provisions the other party has for preserving the privacy of the password.  Users must be distrustful of the other party's security for passwords; users should take precautions to limit the damage that can occur if any password is compromised by means outside of their control.

2.1.4 The desirable arrangement is for an authorization-requesting entity to demonstrate that the  password is known without the password itself being communicated to the authentication function.  This is difficult to arrange without an elaborate protocol that depends on sophisticated use of technology by both parties.  Without cooperation of the other party, users are limited in the precautions that can be taken on their own.

2.2 More Simple than Secure

2.2.1 Typical authentication functions only retain a cryptographic hash of the chosen password.  The authentication function does not retain the password.  Only the cryptographic hash is retained.  In a future request, the then-supplied password is hashed and that hash value is checked against the one on file.  If there is a match, the requester is authenticated. 

2.2.2 The appeal of this arrangement is that the password is only retained by the requester; the requester is primarily responsible for preserving the password's confidentiality.  There is no question that this is preferable to retention of the password itself, including trusting the authentication function to choose the password.  Unfortunately, the password is probably still vulnerable to discovery by a determined adversary.

2.2.3 So long as important assumptions are satisfied, cryptographic hashes are considered to be acceptably one-way functions:  Computing the hash from the password is straightforward but it is prohibitively expensive to find the password given its hash.  Unfortunately, the conditions under which recovery of a password is infeasible are regularly violated.  If someone  possesses the cryptographic hash of a human-chosen password, it is too likely that the password can be found.  There are two consequences: there is compromise of the specific authentication function; there is also compromise of any other authentication function where the same password is used.  By anyone.

2.2.4 Consequently, cryptographic hashes of passwords must be kept at least as private as the password itself.  Systems that keep very large collections of password hashes are high-valued targets for computer penetration and theft.  Such thefts have become commonplace and there is wholesale discovery of passwords that match stolen cryptographic hashes.  In addition, some password hashes are not kept private and are easily obtained.

2.2.5 Once a cryptographic hash has been disclosed, the password is subject to off-line attack.   Networks of adversaries can use high-performance computation techniques to systematically harvest passwords.  This is very different than attempting to make brute-force attacks against an on-line account, an Automated Teller Machine, or a locking screen which will impede repeated trial-and-error attempts.

2.2.6 If a password hash is not private, password compromise must be assumed.  This leads to a situation where whatever the associated privilege might be, the password must not be more valuable and worth discovery by attacking the hash.

2.2.7 Unfortunately, it is not possible for an end-user to control the quality of the procedures for protection of passwords by authentication functions.  The point of control for users is in the uniqueness and other safety qualities of the password that is supplied for use by the authentication function.

2.3 Safety of the Password Is Not Simple

2.3.1 In the typical password-agreement authentication arrangements, there are two important limitations:

2.3.2 Assuming that the inescapable risks of relying on a password-based authorization are accepted as tolerable, here are some mitigations that move closer to the desired arrangement:

2.3.3 Those mitigations limit compromise of any passwords used by the requester.  Focus is on damage-limitation:

2.3.4 This level of safety is costly: Now the requester must create, secure, and manage all of the derived keys for authorizations that must be authenticated for.  (This might be done by an agent of the requester, including software, but the user is responsible for making appropriate use of it.)

2.3.5 Auto-Generated Password Considerations.  There are creative techniques for producing derived keys based on fixed properties of the authenticating service, such as an internet address.  In this case, the derived key does not have to be retained, it is derived each time from a (secret) user-chosen password and the fixed properties.  This is a fragile arrangement if the internet address or other fixed property (including the user-chosen password) changes.  It also needs to be strongly assured that no two users will ever have the same derived key, not even when their privately-held passwords happen to be the same.  (Absent additional precautions in the authentication function, duplicate derived keys will have duplicate cryptographic hashes.)

2.3.6 Determinism Considerations. Derived keys can be made indistinguishable from random values, such that there is no information revealed about any user-chosen password and the probability of duplicates is negligible.  Nevertheless, simple password protocols are deterministic thereafter: The same derived key is used repeatedly for subsequent requests for authorization.  This is unavoidable in the common case of user-chosen passwords (or derived keys) that are arranged in a one-time setup for multiple future authentications.  The situation is aggravated when the space in which derived keys (as passwords) are constrained is so small that brute-force trial-and-error attack is feasible and duplicate derived keys are likely.

3. More Information: Bibliography


Attribution:
Hamilton, Dennis E.
AuthzN Password-Independent Authenticator.   nfoWorks nfoNote folio n120801 0.04, March 2, 2013.  Accessed at <http://nfoWorks.org/notes/2012/08/n120801.htm>.
Revision History:
 
0.04 2013-03-02-11:00 Expand Bibliography
The bibliography is extended to reflect additional information about attacks, compromised schemes, and the general poor situation.  Small adjustments are made to wordings in the text.
  
0.03 2012-12-12-08:19 Added Pass-the-Hash References.
The Microsoft blog post and white paper on PtH Attacks is added for the extensive analysis that is now available.
0.02 2012-12-09-12:56 Update folio to 0.02
The principles are now upgraded for publication as an usable 0.02 version.  Additional bibliography items are added as they are noticed.
0.01 2012-11-26-18:58 Provide Concept Summary with Digest-Replacement Case
The basic approach is summarized and the folio completed enough for cross-reference to the application in ODF documents.
0.00 2012-08-20-13:13 Establish Placeholder for Pending Material
Also start a job jar page for recording work items for building more content. 

Construction Structure (Hard Hat Area)

Creative Commons License You are navigating nfoWorks.
This work is licensed under a
Creative Commons Attribution 2.5 License.

created 2012-05-03-15:57 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 17-04-10 14:09 $
$$Revision: 132 $