n120801 nfoWorks nfoNote AuthzN Password-Independent Keys

nfoWorks>notes> 2012>08> n120801>  0.04 2017-06-14 20:22

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.1.1 Passwords that people choose are easy to compromise.
    
• 1.1.2 Services that require passwords protect them badly. 
    
• 1.1.3 There is little assurance that the protection of sensitive information held by another is as secure as the password itself.
    
• 1.1.4 Sometimes the password is more valuable than what it is used to protect, making attack of the password itself particularly attractive.

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.1.1 The password is communicated by the requester to the authorizing service.  It is presumed that it is not retained by the service.  This leaves the password vulnerable to eavesdropping and to various man-in-the-middle attacks, including compromise of the authorizing service.  It is better that the authorizing service, and everyone in-between, never set eyes on the password.  Not even for a nanosecond.
    
• 2.3.1.2 The communicated password is likely to be one that can be economically recovered from the cryptographic hash by any adversary, including an insider, who gains possession of the hash.  It is better to communicate a code that is infeasible to recover from the cryptographic hash.  That code should not be used for any other authentication purpose; it should be infeasible to recover any password that is somehow associated with that code. 

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.2.1 The authentication request, and the included password, is communicated over a secure channel.  That takes care of the path from a browser, say, to the authorizing service.  Now the only potential eavesdropping is at the end-points of the communication when the password is initially chosen and whenever it is used for subsequent authentication.
     
• 2.3.2.2 Instead of communicating a password, send a derived key that is effectively indistinguishable from a cryptographically-random value (delivered in the accepted format and of adequate length).  The authentication function should store a cryptographic hash of that.  If the derived key can be strong enough, it becomes infeasible to discover the derived key from the retained cryptographic hash.  In the unlikely case that the derived key is discovered, it is still infeasible to determine any password that was involved in its creation.  Here, success depends on the authentication function not severely limiting the form and diversity of derived keys disguised as user-chosen passwords.
    
• 2.3.2.3 Ensure that no derived key is ever used with more than one authentication function.  Have multiple derived keys be unpredictable and unrelated to each other.  In this way, the compromise of one authentication function does not assist in compromise of any other.

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

• 2.3.3.1 It is not known to the authentication function how the derived key is produced.  Any association between an user-chosen password and the derived key is not discoverable.
    
• 2.3.3.2 The derived key is effectively indistinguishable from random; it is infeasible to recover it from a subsequently-derived and stored cryptographic hash by enumeration or trial-and-error.
     
• 2.3.3.3 A collision (a value that is found to hash to the derived-key hash), if ever found, does not disclose anything about any password, including one associated with the derived key by the requester's technique.
     
• 2.3.3.4 Compromise of one derived-key does not cascade to compromise of other derived keys nor any associated password that they have in common.

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

• n120801b: authzN Principles [latest]
        
• n120801c: authzN Essential Principles
• n120801a: Diary & Job Jar
    
• Office of Inadequate Security.  (web site) <http://www.databreaches.net>
  Visit this site to see that deluge of data-breach and other problems concerning confidentiality failures, including compromise of passwords and theft of their digital hashes.  There is a newsfeed.
• Threatpost. (web site) <http://www.threatpost.com/>
  Dealing with a broader range of exploits, this news service is also valuable in learning about threats that may impact ones personal information.
• Schneier on Security. (blog) <http://www.schneier.com/>
  This blog deals with security at all levels, providing links and commentaries from a well-known security expert.
    
• Microsoft Corporation.  Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques: mitigating the risk of lateral movement and privilege escalation.  White paper.  (2012).  Accessed on 2012-12-12 via Tim Rains blog post.
  This document provides a comprehensive explanation and assessment of mitigations around password and credential exploits.  The mitigation is for providers who retain password information for authorization purposes, in contrast with the focus of AuthzN on mitigation for those who must rely on providers of unknown quality.  The term "lateral movement" is used where I have used "transitive exploit".
    
• Wikipedia.  Cryptographic hash function. (web page).  2012-11-01 version at <http://en.wikipedia.org/w/index.php?title=Cryptographic_hash_function&oldid=520889212>
    
• Wikipedia.  One-way function. (web page).  2012-10-11 version at <http://en.wikipedia.org/w/index.php?title=One-way_function&oldid=517186440>
    
• Evernote Corporation.  Security Notice: Service-Wide Password Reset.  (Corporate News web page) evernote.com 2013-03-02, accessed at <http://evernote.com/corp/news/password_reset.php>.
  This is a commonplace occurrence.  There is simple advice for what users should do to limit their exposure to such intrusions.  The organization also provides an account for the precautions it takes.  However, the "user names, email addresses, ... and encrypted passwords" were accessible in the penetration.  In general it is necessary to assume the unencrypted password is compromised wherever that password is also used.
   
• Saita, Anne.  Study Shows One in Four Who Receive Data Breach Letter Become Fraud Victims (blog post).  Data Breaches section, Threat Post 2013-02-20, accessed at <http://threatpost.com/en_us/blogs/study-shows-one-four-who-receive-data-breach-letter-become-fraud-victims-022013>.
  This is not just about passwords. It is about any breach that discloses private information, including information that might be password protected for access by the person the information applies to.  The information may have been disclosed directly by accident or system breach, not just by password compromise.  The statistics on how valuable these breaches are to those who perpetrate them is frightening.  Even when there is indemnification of individual victims, the individual cost to recovery from an identity theft is scary, and the experience of violation by the victims should be disturbing to us all.  The good news is that many more folks than we imagine among those who experience data breaches are also vigilant and act quickly.  It is also a demonstration of the level of distrust there is for organizations and institutions having custody of our personal information.
    
• Singer, Natasha.  If You're Collecting Our Data, You Ought to Protect It.  The New York Times, Slipstream article (on-line), 2013-02-16, accessed at <http://www.nytimes.com/2013/02/17/technology/if-youre-collecting-our-data-you-ought-to-protect-it.html>.
    
• Hamilton, Dennis E.  Improving Hashes Doesn't Improve Passwords.  (blog post) Orcmid's Live Hideout, 2013-02-15, accessed at <http://orcmid.wordpress.com/2013/02/15/improving-hashes-doesnt-improve-passwords/>.
    
• Rains, Tim.  Mitigating Attacks on Your Organization.  (Microsoft Technet blog post) Trustworthy Computing.  2012-12-11, accessed at <http://blogs.technet.com/b/trustworthycomputing/archive/2012/12/11/mitigating-targeted-attacks-on-your-organization.aspx>. 
  Points out pass-the-hash as a common point of leverage.
    
• Schneier, Bruce.  When It Comes to Security, We're Back to Feudalism. (opinion article) Wired, 2012-11-26, accessed at <http://www.wired.com/opinion/2012/11/feudal-security/>
    
• Honan, Matt.  The New York Times Is Wrong: Strong Passwords Can't Save Us.  (web page) Wired, 2012-11-15, accessed at <http://www.wired.com/gadgetlab/2012/11/why-no-password-is-safe-from-hackers/>
    
• Honan, Matt.  Kill the Password: Why a String of Characters Can't Protect Us Anymore.  (web page) Wired, 2012-11-15, accessed at <http://www.wired.com/gadgetlab/2012/11/ff-mat-honan-password-hacker/all/>
    
• Gordon, Whitson.  EA Origin Hacked: Time to Change Your Password.  (blog post) Lifehacker, 2012-11-14, accessed at <http://lifehacker.com/5960676/>
    
• Kumar, Vikas N.  Wisecracker  (web page).  Selective Intellect LLC.  Accessed on 2012-11-13 at <http://selectiveintellect.com/wisecracker.html>
    
• Perlroth, Nicole.  Hacker Claims to Have Breached Adobe.  (Bits blog) The New York Times, 2012-10-14, accessed at <http://bits.blogs.nytimes.com/2012/11/14/hacker-claims-to-have-breached-adobe/>
    
• Caudill, Adam.  UPEK Windows Password Decryption. (blog post) Adam Caudill, 2012-10-07, accessed at <http://adamcaudill.com/2012/10/07/upek-windows-password-decryption/>
     An useful demonstration of how clumsily password-protection schemes are devised.  There are further examples in this blog.
    
• Fisher, Dennis.  Passwords are Dead, Long Live Passwords.  (blog post) Threatpost 2012-07-12, accessed at <http://threatpost.com/en_us/blogs/passwords-are-dead-long-live-passwords-071212>
    
• Stevens, John.  Securing Password Digests - or - How to Protect Lonely Unemployed Radio Listeners.    Justice League Blog, 2012-06-12, accessed at <http://www.cigital.com/justice-league-blog/2012/06/11/securing-password-digests-or-how-to-protect-lonely-unemployed-radio-listeners/>
  For me, this is a demonstration of how convoluted the efforts to develop some sort of secure password-based authentication can become.  As far as I can tell, the post ends up approximating PBKDF2 without the iteration.  It does discuss the terrible weakness of the even-weaker schemes that are commonplace, however convoluted their implementations.  At the end, addition of a second secret (not from the password-holder) is attempted.  This reverts to the previously-unsolved problem of protecting the digest value itself and other private information retained by the service that is accessible with the password.
     
• Hamilton, Dennis E.  Password Security 1: Social Engineering an SHA1 Hack.  (blog post)  Orcmid's Live Hideout, June 7, 2012.  Available at <http://orcmid.wordpress.com/2012/06/07/password-security-1-social-engineering-an-sha1-hack/>
    
• Graham, Robert David.  Confirmed: LinkedIn 6mil password dump is real.  (blog post) Errata Security, 2012-06-06.  Accessed at <http://erratasec.blogspot.com/2012/06/confirmed-linkedin-6mil-password-dump.html>.
     There is a comprehensive discussion of how the disclosed dump of LinkedIn passwords was checked, with estimation of how rapidly these could be cracked with conventional PC hardware having a high-performance graphics adapter.
    
• Whittaker, Zack.  6.46 million LinkedIn passwords leaked online.  (Between the Lines blog) ZDNet, 2012-06-06.  Accessed at <http://www.zdnet.com/blog/btl/6-46-million-linkedin-passwords-leaked-online/79290>
    
• Hamilton, Dennis E.  OASIS OIC TC Interop Advisory 00009: Protection-Key Safety.  OASIS ODF Interoperability and Conformance (OIC) TC SVN repository, 2011-10-04, 2012-06-13 working draft 9 accessed on 2013-02-21 at <https://tools.oasis-open.org/version-control/svn/oic/Advisories/00009-ProtectionKeySafety/trunk/description.html>.
  This is about situations where digests are easily retrieved and usable in transitive/lateral attacks, and their particular vulnerability when the password is itself used for other, more-valuable secrets.
    
• Hunt, Troy.  The Only Secure Password Is the One You Can't Remember.  (web article) Lifehacker, 2011-03-24.  Available at <http://lifehacker.com/5785420/the-only-secure-password-is-the-one-you-cant-remember>
     This is a nicely comprehensive discussion of why and how to create unique passwords that are in a protected collection using available tools.
    
• Hamilton, Dennis E. ... And It Came to Pass.  (blog post)  Orcmid's Lair, April 17, 2010.  Available at <http://orcmid.com/blog/2010/04/and-it-came-to-pass.asp>
    
• Hamilton, Dennis E.  Document-Security Theater: When the Key is More Valuable than the Lock. (blog post)  Orcmid's Lair, updated February 13, 2010.  Available at <http://orcmid.com/blog/2010/02/document-security-theater-when-key-is.asp>
    
• Adida, Ben.  Don't Hash Secrets. (blog post) Benlog, June 19, 2008.  Available at <http://benlog.com/articles/2008/06/19/dont-hash-secrets/>
     This advice is particularly useful for those entrusted with user-chosen passwords. 
    
• Schneir, Bruce.  Cryptanalysis of SHA-1. (blog post) Schneier on Security, February 18, 2005.  Accessed at <http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html>.

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. 

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-06-14 20:22 $ $$Revision: 136 $