Industry:Draft NIST SP 800-118

Return to Global Industry Committee

Submission Response
Latest first

Final version
TBC

Comments
Add comments, additions, changes on draft 1 here please, or to lists or directly to CW

Summary
One page summary with three recommendations

...

...

Recommendations


 * place greater emphasis on the many systems available over untrusted networks or by untrusted clients, such as web applications
 * web application development teams should consider the password management issues in A Guide to Building Secure Web Applications and Web Services
 * the authentication requirements in the Application Security Verification Standard should (ASVS) also be used to assess enterprise password management in web applications

The detailed response follows.

==== 2 Introduction to Passwords and Password Management ====

Explanation Resources that require protection are sometimes available without authentication, or the password-based authentication mechanisms may not be implemented correctly. Reference: Authentication Verification Requirements, Application Security Verification Standard (ASVS) Web Application Edition, 2008, OWASP http://www.owasp.org/index.php/ASVS

Suggested changes At the end of the third paragraph add "It is important to verify that all files, web pages, etc protected by the password mechanism actually require authentication. The authentication controls across a web application should be verified against standards such as Application Security Verification Standard (ASVS) Web Application Edition from OWASP."

3.1.1 Password Capturing : Storage
Explanation Use of the "autocomplete" attribute is recommended for HTML form elements containing sensitive data. "Remember me" functionality on public computers, where a user can simply return to their personalized account can be dangerous. Reference 1: Authentication - Browser Remembers Passwords, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project Reference 2: Authentication - Remember Me, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project

Suggested changes Add "For a web application, the 'autocomplete' attribute should be implemented with the value 'off' in rendered HTML form fields, or whole HTML forms, where sensitive data such as passwords are entered, but this should not be relied upon. Additionally, avoid the use of 'remember me' functionality on public systems, especially where more sensitive data is accessed or the application is considered to be a higher risk.  If 'remember me' is implemented, do not turn it on by default, advise users of the risks before they opt in and never use a predictable 'pre-authenticated' token."

3.1.2 Password Capturing : Transmission
Explanation Web Services must not send passwords in plain text. Replay attacks are a significant type of vulnerability found in web applications. Reference 1: Web Services, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project  Reference 2: Session Management -  Session Token Replay, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project

Suggested changes In the bulleted list, change the end of the 3rd item from "Examples are switching from telnet to Secure Shell (SSH) and from HTTP to HTTP Secure (HTTPS)." to "Examples are using WS-Security (Web Services Security), switching from telnet to Secure Shell (SSH) and from HTTP to HTTP Secure (HTTPS).". Add " Privacy of data in transit is paramount and web applications should guard against replay attacks by careful design of session management - the addition of entropy, secret key, salt is also a good approach for transmission of passwords over a non encrypted tunnel. Message hashing (with salt), which includes a nonce, also helps prevent replay.  the There should also be provision of a robust logout mechanism (which destroys the session server side e.g. deletes the session cookie in a web application), inclusion of a logout link or button in every view on every page which requires authentication, and content anti-caching measures."

3.1.3 Password Capturing : User Knowledge and Behavior
Explanation Sharing of passwords and use of passwords revealed through social engineering are a particular threat to web applications. Reference 1: Phishing, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project  Reference 2: Session Management - Session Token Replay, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project

Suggested change Add "For web applications, use session fixation controls to strongly tie a single browser to a single session and prevent multiple sessions by the same user. Users should be provided with information on previous successful and unsuccessful login attempts and activities undertaken to help them identify potential mis-use of their own account. If an event occurs, the account owner should be informed of the event via out-of-band means (see also 3.3.1). "

3.2.1 Password Guessing and Cracking : Guessing
Explanation Web applications can be particularly vulnerable to password guessing, where the attacker could have continual access to the target system. Reference 1: Authentication - Change Password, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project Reference 2: Authentication - Brute Force, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project

Suggested changes In the first bullet point, add "On public systems such as web applications, a lower threshold of 5 or 10 failed attempts would be more common." Add "For web applications, the system also needs to guard against distributed guessing attacks, where different user accounts may be targeted and/or different sessions/hosts are used to launch the attack simultaneously. One example of this is reverse brute force where the same password is tried repeatedly but the attacker cycles through user account identities. '" Add "Password change mechanisms should require entry of the old password and enforce protection against guessing attacks in the same was as the login."

3.3.1 Password Replacing : Forgotten Password Recovery and Resets
Explanation Password reset mechanisms vary in complexity, and are often implemented less securely than login mechanisms. Reference: Authentication - Automated Password Resets, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project

Suggested change Add "For publicly accessible systems such as web applications, password recovery should not be implemented. Instead password reset tied with some out-of-band communication should be used e.g. for a web application, out-of-band might be mobile phone sms, or email, or conventional post ."

3.4 Using Compromised Passwords
Explanation If we accept that some passwords will be compromised, it is important that accounts have the minimum privileges necessary. Thus, a read-only user shouldn't be able to create, update and delete data for example, or undertake administrative functions. Reference: Secure Coding Principles - Security Principles - Principle of Least Privilege, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project

Suggested change Add "The account accessed, using any password, should have the minimum permissions least privilege to undertake the required functionality."

About OWASP
This response is submitted on behalf of the Open Web Application Security Project (OWASP) http://www.owasp.org/. OWASP is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license. The OWASP Foundation is a U.S. recognized 501(c)(3) not-for-profit charitable organization, that ensures the ongoing availability and support for our work at OWASP.

Further information:


 * OWASP Foundation
 * About The Open Web Application Security Project
 * The Open Web Application Security Project

3.1.1 Password Capturing : Storage
Explanation Use of the "autocomplete" attribute is recommended for HTML form elements containing sensitive data. "Remember me" functionality on public computers, where a user can simply return to their personalized account can be dangerous. Reference 1: Authentication - Browser Remembers Passwords, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project Reference 2: Authentication - Remember Me, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project

Suggested changes Add "For a web application, the 'autocomplete' attribute should be implemented with the value 'off' in rendered HTML form fields, or whole HTML forms, where sensitive data such as passwords are entered, but this should not be relied upon. Additionally, avoid the use of 'remember me' functionality on public systems, especially where more sensitive data is accessed or the application is considered to be a higher risk.  If 'remember me' is implemented, do not turn it on by default, advise users of the risks before they opt in and never use a predictable 'pre-authenticated' token."

3.1.2 Password Capturing : Transmission
Explanation Web Services must not send passwords in plain text. Replay attacks are a significant type of vulnerability found in web applications. Reference 1: Web Services, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project  Reference 2: Session Management -  Session Token Replay, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project

Suggested changes In the bulleted list, change the end of the 3rd item from "Examples are switching from telnet to Secure Shell (SSH) and from HTTP to HTTP Secure (HTTPS)." to "Examples are using WS-Security (Web Services Security), switching from telnet to Secure Shell (SSH) and from HTTP to HTTP Secure (HTTPS).". Add "Web applications should guard against replay attacks by careful design of session management, the provision of a robust logout mechanism, inclusion of a log out link or button in every view and content anti-caching measures."

3.1.3 Password Capturing : User Knowledge and Behavior
Explanation Sharing of passwords and use of passwords revealed through social engineering are a particular threat to web applications. Reference 1: Phishing, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project  Reference 2: Session Management - Session Token Replay, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project

Suggested change Add "For web applications, use session fixation controls to strongly tie a single browser to a single session and prevent multiple sessions by the same user. Users should be provided with information on previous successful and unsuccessful login attempts and activities undertaken to help them identify potential mis-use of their own account."

3.2.1 Password Guessing and Cracking : Guessing
Explanation Web applications can be particularly vulnerable to password guessing, where the attacker could have continual access to the target system. Reference 1: Authentication - Change Password, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project Reference 2: Authentication - Brute Force, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project

Suggested change In the first bullet point, add "On public systems such as web applications, a lower threshold of 5 or 10 failed attempts would be more common." Add "For web applications, the system also needs to guard against distributed guessing attacks, where different user accounts may be targeted and/or different sessions/hosts are used to launch the attack simultaneously." Add "Password change mechanisms should require entry of the old password and enforce protection against guessing attacks in the same was as the login."

3.3.1 Password Replacing : Forgotten Password Recovery and Resets
Explanation Password reset mechanisms vary in complexity, and are often implemented less securely than login mechanisms. Reference: Authentication - Automated Password Resets, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project

Suggested change Add "For publicly accessible systems such as web applications, password recovery should not be implemented. Instead password reset tied with some out-of-band communication should be used."

3.4 Using Compromised Passwords
Explanation If we accept that some passwords will be compromised, it is important that accounts have the minimum privileges necessary. Thus, a read-only user shouldn't be able to create, update and delete data for example, or undertake administrative functions. Reference: Secure Coding Principles - Security Principles - Principle of Least Privilege, A Guide to Building Secure Web Applications and Web Services, v2.0.1, OWASP http://www.owasp.org/index.php/Category:OWASP_Guide_Project

Suggested change Add "The account accessed, using any password, should have the minimum permissions to undertake the required functionality."

About OWASP
This response is submitted on behalf of the Open Web Application Security Project (OWASP) http://www.owasp.org/. OWASP is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license. The OWASP Foundation is a U.S. recognized 501(c)(3) not-for-profit charitable organization, that ensures the ongoing availability and support for our work at OWASP.

Further information:


 * OWASP Foundation
 * About The Open Web Application Security Project
 * The Open Web Application Security Project

Return to Global Industry Committee