Passwords are important and it's no secret that we are bad in finding complex passwords during sign-up processes. The initial idea of OneID, or OAuth is not doing very well for the common user, and therefore people are registering on 100s of websites - commercial, social networks, banks etc. without managing well with password complexities. While the tools to crack 8-10 characters passwords are speeding up the process, people are still resenting to keep passwords more than 6 characters long with minimum complexity.
Digital authentication is all around us and is exponentially accelerating with the advent of IOT devices. All your social networks, banks, email providers digitally authenticate you before authorizing you to use their services. It also insures the confidentiality of your data, and integrity of the communications from your respective accounts. The new document Digital Authentication Guideline is open for public review via Github.
Note: All the highlighted texts in this blog have been extracted from respective documents directly. These texts can change as the 4 document(s) are going under review.
- Digital Authentication Guideline (SP 800-63-3)
- Identity Proofing & Enrollment (SP 800-63A)
- Authentication & Lifecycle Management (SP 800-63B)
- Federation & Assertions (SP 800-63C)
As per NIST,== a new approach for digital authentication solutions is required by these guidelines, separating the individual elements of identity assurance into discrete, component parts==. These 3 key components of assurance levels are,
- IAL or Identity Assurance Level
- AAL or Authenticator Assurance Level
- FAL or Federation Assurance Level
In cases of non-Federated Systems, agencies will select and combine 2 components - IAL and AAL. For Federated systems, the 3rd FAL is required. The table below shows the new requirements that are allowable for M-04-04 Level of Assurance, by combining IAL, AAL, and FAL based on agency need.
- Minimum password length is 8 characters (can be increased depending on the sensitivity of the application). Or, 6 digit PIN if digital pin-pad. Earlier it was 6 chars/ 4 digits.
- Allow all printable ASCII characters and spaces. Should also accept UNICODES. Some values for user-chosen memorized secrets may be disallowed based on their appearance on a blacklist of compromised values. No other complexity requirements for memorized secrets are imposed.
- The concept of storing hints is off the table now. Verifiers also SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.
- Verifiers must implement a mechanism to prevent brute-force attacks.
- Verifiers should not initiate secrets to be changed arbitrarily (e.g., periodically) unless there is evidence of compromise.
- In order to assist the subscriber in entering a memorized secret successfully, the verifier should offer an option to display the secret (unmask asterisks/dots) as it is typed.
- Verifiers SHALL use approved encryption and SHALL authenticate themselves to the claimant
- Verifiers must store memorized secrets in a form resilient to offline attacks, such as hashed with a salt value using an approved key based hash function.
That's it for now, and I will keep on updating this document with new points as the review progresses.
I would highly encourage you to participate in the review process.
Update 1: 22-Aug-2016
Key points related to OOB (Out of Band) Authenticators are,
- Delivered using approved devices and crypto.
- SMS is deprecated and also, shall not be delivered to a VOIP number.
- Biometric devices must have attempt limits to 10.