You are here

OPEN TOPIC: Replacing User Name/Password Defaults - Alternative User Authentication Methods

Description:

OUSD (R&E) CRITICAL TECHNOLOGY AREA(S): Human-Machine Interfaces

 

OBJECTIVE: DTRA seeks technologies to replace the user name/password default for authenticating users in various applications and services.  The alternative proposed should be compatible with existing and emerging cloud/cloud-capable architectures, reduce the operational overhead for support, increase security over username/password defaults, and be ‘user-friendly’ to employ at the user interface application.

 

DESCRIPTION: While the principal user authentication used is the Public Key Encryption (PKI) used in tokens (Common Access Cards (CACs), Personal Identity Verification (PIV) cards, etc.), the continued support of username/password authentication in some use cases poses an unwelcome burden to the services provided.  Current password implementations require (increasingly longer) passwords containing mixes of upper case, lower case, numerical and special characters, which must be changed every 60 – 90 days without repeating passwords maintained on lists for the previous 10-24 valid passwords.  Brute force password cracking approaches have improved success rates employing parallelization of GPU and specialized hardware such as floating-point gate arrays (FPGAs) over the previous attempts using high-powered CPUs.  A class of cryptologic techniques called ‘memory hard’ make these approaches ineffective, and form one of the key specific objectives for evaluation in this proposal.  While commercial tokens (e.g. RSA and ORC PKI) are available to the public, they are not suitable for the first responders and foreign partners this topic supports due to various reasons (cost, availability, operational support and management, etc.)  While token-based approaches are allowed for consideration, token-less approaches are preferred given the previously stated concerns.  The World Wide Web Consortium (W3C) and the Fast IDentity Online (FIDO) Alliance are the principal bodies establishing standards, which various government agencies accept as governing standards.  However, the new password-less standard known as FIDO2, endorsed formally by Apple, Google, and Microsoft, suffer from two issues in this initial implementation:  The three major companies adopting this standard are deploying three incompatible proprietary systems, subjecting users to maintaining multiple credentials per supported website to accommodate devices in each ecosystem.  That imposes a burden on users for not only certificate maintenance per site and device, but also for transporting and maintaining that certificate cache securely across their individual devices and platforms.  That limitation is not as important a concern for this topic and our use cases, but is critical for future commercial interests.  The second current FIDO2 implementation problem is that each user’s PKI certificate for each website must be stored in the cache (again multiplied per vendor).  Caching of the certificate is a departure from the FIDO token PKI implementation that supports existing CAC/PIV architectures used by government agencies and is a principal requirement for this proposal topic.  In summary, the attributes desired for any proposed solutions for this topic are:

• Solution must be a dramatic improvement in security, operation support and/or user experience for authenticating and managing disadvantaged users to replace username/password baseline

• Encryption method must be a proven ‘memory hard’ approach and implementation to counter parallelized GPU/FPGA brute force or intelligent guessing to spoof authentication communications

• System must be immune (or highly resistant) to common security compromise strategies; for example, such as ‘man in the middle’ or intercepted data replay attacks.

• System must be standards compliant or compatible, e.g. compliant with or compatible to FIDO2 guidelines

• System must be a vendor independent solution; e.g. must not be constrained to a single vendor’s ecosystem or platform, and not impose large overhead in storing or transferring user credentials across supported systems.  This dramatically reduces any migration issues across domains.

 

 

PHASE I: Analyze alternative approaches, providing at least two options to include summaries of technical feasibility of implementation and integration with existing systems, operations and maintenance for principal alternatives.  Demonstrate depth of understanding through a detailed technical report for preferred option illustrating deployment into “as is” authentication systems with PKI as principal authentication method, but using username/PW as the default targeted for replacement by this investigation.  The report should include a proposal for Phase II prototype development.  The prototype should be developed not only to merge into existing DoD or other government agencies’ systems, but should also be flexible enough for commercial deployment, such as small and medium businesses, local first responders, hospitals and clinics, etc.

 

PHASE II: Implement a fully functional prototype of the proposed solution, to include server-side added functionality to support the concept to the user side authentication application.  The prototype should be amenable to functional and security testing.  The prototype should be capable of being implemented in either traditional application-centric or cloud services environments.  Documentation should include user, operational and testing information.

 

PHASE III DUAL USE APPLICATIONS: Implement further improvements that would enhance use of the developed product by the sponsoring office, identify and exploit features that would be attractive for commercial or other applications.  Expand upon the documentation developed in Phase II to include improvements implemented in Phase III.  Investigate commercialization avenues that could include other government agencies, national labs, research institutes, and defense contractors.  Develop a plan to enable successful technology transition at the end of this phase. 

 

REFERENCES:

  1. Open Web Application Security Project (OWASP) Top Ten, https://owasp.org/www-project-top-ten/
  2. FIDO Alliance – Authentication Specifications Overview, https://fidoalliance.org/specifications/
  3. Memory-Hard Functions from Cryptographic Primitives, https://par.nsf.gov/servlets/purl/10121369
  4. Tradeoff Cryptanalysis of Memory-Hard Functions https://eprint.iacr.org/2015/227.pdf

 

KEYWORDS: Secure authentication, PKI, Hard memory implementation, Simplified Migration

 

US Flag An Official Website of the United States Government