This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Top 10-2017 A2-Broken Authentication"

From OWASP
Jump to: navigation, search
m (Editorial changes e.g. line feeds, bold or underlined text)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
{{Top_10_2013:TopTemplate
 
{{Top_10_2013:TopTemplate
     |usenext=2013NextLink
+
    |useprev=2017PrevLink
 +
    |prev=A1-{{Top_10_2010:ByTheNumbers
 +
        |1
 +
        |year=2017
 +
        |language=en
 +
    }}
 +
     |usenext=2017NextLink
 
     |next=A3-{{Top_10_2010:ByTheNumbers
 
     |next=A3-{{Top_10_2010:ByTheNumbers
              |3
+
        |3
              |year=2017
+
        |year=2017
              |language=en}}
+
        |language=en
     |useprev=2013PrevLink
+
     }}
    |prev=A1-{{Top_10_2010:ByTheNumbers
 
              |1
 
              |year=2017
 
              |language=en}}
 
 
     |year=2017
 
     |year=2017
 
     |language=en
 
     |language=en
 
}}
 
}}
 
+
<!--- 2017 Broken Authentication --->
 
{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
 
{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
{{Top_10:SummaryTableTemplate|exploitability=2|prevalence=2|detectability=2|impact=1|year=2017|language=en}}
+
{{Top_10-2017:SummaryTableTemplate|exploitability=3 |prevalence=2 |detectability=2 |impact=3 |year=2017|language=en}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
+
    <td colspan=2 {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}>
Consider anonymous external attackers, as well as authorized users, who may attempt to steal accounts from others. Also consider insiders wanting to disguise their actions.
+
<!--- Threat Agent: --->
</td>
+
Attackers have access to hundreds of millions of valid username and password combinations for credential stuffing, default administrative account lists, automated brute force, and dictionary attack tools. Session management attacks are well understood, particularly in relation to unexpired session tokens.</td>
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
+
    <td colspan=2 {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}>
Attackers use leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to temporarily or permanently impersonate users.
+
<!--- Security Weakness: --->
 
+
The prevalence of broken authentication is widespread due to the design and implementation of most identity and access controls. Session management is the bedrock of authentication and access controls, and is present in all stateful applications.<br/>Attackers can detect broken authentication using manual means and exploit them using automated tools with password lists and dictionary attacks.</td>
</td>
+
    <td colspan=2 {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}>
    <td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
+
<!--- Impacts: --->
Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, create account, change password, forgot password, timeouts, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique.
+
Attackers have to gain access to only a few accounts, or just one admin account to compromise the system. Depending on the domain of the application, this may allow money laundering, social security fraud, and identity theft, or disclose legally protected highly sensitive information.</td>
 
+
{{Top_10_2010:SummaryTableEndTemplate|year=2017}}
</td>
 
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
Such flaws may allow some or even all accounts to be attacked. Once successful, the attacker can do anything the victim could do. Privileged accounts are frequently targeted.
 
 
 
</td>
 
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}>
 
Consider the business value of the affected data or application functions.
 
  
Also consider the business impact of public exposure of the vulnerability.
+
{{Top_10:SubsectionTableBeginTemplate|type=main}}
 
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=isTheApplicationVulnerable|position=firstLeft|year=2017|language=en}}
</td>
+
Confirmation of the user's identity, authentication, and session management are critical to protect against authentication-related attacks.
{{Top_10_2010:SummaryTableEndTemplate|year=2017}}
+
There may be authentication weaknesses if the application:
 +
* Permits automated attacks such as <u>[[Credential_stuffing|credential stuffing]]</u>, where the attacker has a list of valid usernames and passwords.
 +
* Permits brute force or other automated attacks.
 +
* Permits default, weak, or well-known passwords, such as "Password1" or "admin/admin“.
 +
* Uses weak or ineffective credential recovery and forgot-password processes, such as "knowledge-based answers", which cannot be made safe.
 +
* Uses plain text, encrypted, or weakly hashed passwords (see <u><b>[[{{Top_10:LanguageFile|text=documentRootTop10New|language=en|year=2017 }}_A3-{{Top_10_2010:ByTheNumbers|3|year=2017|language=en}} | A3:2017-{{Top_10_2010:ByTheNumbers|3|year=2017|language=en}}]]</b></u>).
 +
* Has missing or ineffective multi-factor authentication.
 +
* Exposes Session IDs in the URL (e.g., URL rewriting).
 +
* Does not rotate Session IDs after successful login.
 +
* Does not properly invalidate Session IDs. User sessions or authentication tokens (particularly single sign-on (SSO) tokens) aren't properly invalidated during logout or a period of inactivity.
  
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=1|risk=2|year=2017|language=en}}
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howToPrevent|position=right|year=2017|language=en}}
Are session management assets like user credentials and session IDs properly protected? You may be vulnerable if:
+
* Where possible, implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential re-use attacks.
# User authentication credentials aren’t properly protected when stored using hashing or encryption. See <u>[[{{Top_10:LanguageFile|text=documentRootTop10|language=en|year=2017 }}-A6-{{Top_10_2010:ByTheNumbers|6|year=2017|language=en}}|2017-A6]]</u>.
+
* Do not ship or deploy with any default credentials, particularly for admin users.
# Credentials can be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs).
+
* Implement weak-password checks, such as testing new or changed passwords against a list of the <u>[https://github.com/danielmiessler/SecLists/tree/master/Passwords top 10000 worst passwords]</u>.
# Session IDs are exposed in the URL (e.g., URL rewriting).
+
* Align password length, complexity and rotation policies with <u>[https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret NIST 800-63 B's guidelines in section 5.1.1 for Memorized Secrets]</u> or other modern, evidence based password policies.
# Session IDs are vulnerable to <u>[[Session_fixation | session fixation]]</u> attacks.
+
* Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes.
# Session IDs don’t timeout, or user sessions or authentication tokens (particularly single sign-on (SSO) tokens) aren’t properly invalidated during logout.
+
* Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected.
# Session IDs aren’t rotated after successful login.
+
* Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session IDs should not be in the URL, be securely stored and invalidated after logout, idle, and absolute timeouts.
# Passwords, session IDs, and other credentials are sent over unencrypted connections. See <u>[[{{Top_10:LanguageFile|text=documentRootTop10|language=en|year=2017 }}-A6-{{Top_10_2010:ByTheNumbers|6|year=2017|language=en}}|2017-A6]]</u>.
 
See the <u>[[ASVS]]</u> requirement areas V2 and V3 for more details.
 
  
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=2|risk=2|year=2017|language=en}}
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=exampleAttackScenarios|position=left|year=2017|language=en}}
The primary recommendation for an organization is to make available to developers:
+
<b>Scenario #1</b>: <u>[[Credential_stuffing|Credential stuffing]]</u>, the use of <u>[https://github.com/danielmiessler/SecLists lists of known passwords]</u>, is a common attack. If an application does not implement automated threat or credential stuffing protections, the application can be used as a password oracle to determine if the credentials are valid.
<ol>
 
<li>'''A single set of strong authentication and session management controls.''' Such controls should strive to:
 
<ol type="a">
 
<li>meet all the authentication and session management requirements defined in OWASP’s <u>[[ASVS|Application Security Verification Standard (ASVS)]]</u> areas V2 (Authentication) and V3 (Session Management).</li>
 
<li>have a simple interface for developers. Consider the <u>[https://static.javadoc.io/org.owasp.esapi/esapi/2.1.0.1/org/owasp/esapi/Authenticator.html ESAPI Authenticator and User APIs]</u> as good examples to emulate, use, or build upon.</li>
 
</ol>
 
</li>
 
<li>Strong efforts should also be made to avoid XSS flaws which can be used to steal session IDs. See <u>[[{{Top_10:LanguageFile|text=documentRootTop10|language=en|year=2017 }}-A3-{{Top_10_2010:ByTheNumbers|3|year=2017|language=en}}|2017-A3]]</u>.</li>
 
</ol>
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=3|risk=2|year=2017|language=en}}
 
<u>'''Scenario #1:'''</u> Airline reservations application supports URL rewriting, putting session IDs in the URL:
 
{{Top_10_2010:ExampleBeginTemplate|year=2017}}<b><nowiki>h</nowiki>ttp://example.com/sale/saleitems<span style="color: red;">;<br/>sessionid=268544541</span>&dest=Hawaii</b>
 
{{Top_10_2010:ExampleEndTemplate|year=2017}}
 
An authenticated user of the site wants to let their friends know about the sale. User e-mails the above link without knowing they are also giving away their session ID. When the friends use the link they use user’s session and credit card.
 
  
<u>'''Scenario #2''':</u> Application’s timeouts aren’t set properly. User uses a public computer to access site. Instead of selecting “logout” the user simply closes the browser tab and walks away. An attacker uses the same browser an hour later, and that browser is still authenticated.
+
<b>Scenario #2</b>: Most authentication attacks occur due to the continued use of passwords as a sole factor. Once considered best practices, password rotation and complexity requirements are viewed as encouraging users to use, and reuse, weak passwords. Organizations are recommended to stop these practices per NIST 800-63 and use multi-factor authentication.
  
<u>'''Scenario #3''':</u> An insider or external attacker gains access to the system’s password database. User passwords are not properly hashed and salted, exposing every users’ password.
+
<b>Scenario #3</b>: Application session timeouts aren't set properly. A user uses a public computer to access an application. Instead of selecting “logout” the user simply closes the browser tab and walks away. An attacker uses the same browser an hour later, and the user is still authenticated.
  
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=4|risk=2|year=2017|language=en}}
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|year=2017|language=en}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate|year=2017}}<br/>
+
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate|year=2017|language=en}}
For a more complete set of requirements and problems to avoid in this area, see the <u>[[ASVS | ASVS requirements areas for Authentication (V2) and Session Management (V3)]]</u>.
+
* <u>[[OWASP_Proactive_Controls#5:_Implement_Identity_and_Authentication_Controls|OWASP Proactive Controls: Implement Identity and Authentication Controls]]</u>
* <u>[[Authentication_Cheat_Sheet | OWASP Authentication Cheat Sheet]]</u>
+
* <u>[[:Category:OWASP_Application_Security_Verification_Standard_Project#tab=Home|OWASP Application Security Verification Standard: V2 Authentication]]</u>
* <u>[[Forgot_Password_Cheat_Sheet | OWASP Forgot Password Cheat Sheet]]</u>
+
* <u>[[:Category:OWASP_Application_Security_Verification_Standard_Project#tab=Home|OWASP Application Security Verification Standard: V3 Session Management]]</u>
* <u>[[Password_Storage_Cheat_Sheet|OWASP Password Storage Cheat Sheet]]</u>
+
* <u>[[Testing_Identity_Management|OWASP Testing Guide: Identity]]</u>, <u>[[Testing_for_authentication|Authentication]]</u>
* <u>[[Session_Management_Cheat_Sheet | OWASP Session Management Cheat Sheet]]</u>
+
* <u>[[Authentication_Cheat_Sheet|OWASP Cheat Sheet: Authentication]]</u>
* <u>[[Testing_for_authentication | OWASP Testing Guide: Chapter on Authentication]]</u>
+
* <u>[[Credential_Stuffing_Prevention_Cheat_Sheet|OWASP Cheat Sheet: Credential Stuffing]]</u>
 +
* <u>[[Forgot_Password_Cheat_Sheet|OWASP Cheat Sheet: Forgot Password]]</u>
 +
* <u>[[Session_Management_Cheat_Sheet|OWASP Cheat Sheet: Session Management]]</u>
 +
* <u>[[OWASP_Automated_Threats_to_Web_Applications|OWASP Automated Threats Handbook]]</u>
  
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2017|language=en}}
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2017|language=en}}
* <u>[http://cwe.mitre.org/data/definitions/287.html CWE Entry 287 on Improper Authentication]</u>
+
* <u>[https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret NIST 800-63b: 5.1.1 Memorized Secrets]</u>
* <u>[http://cwe.mitre.org/data/definitions/384.html CWE Entry 384 on Session Fixation]</u>
+
* <u>[https://cwe.mitre.org/data/definitions/287.html CWE-287: Improper Authentication]</u>
 +
* <u>[https://cwe.mitre.org/data/definitions/384.html CWE-384: Session Fixation]</u>
  
 
{{Top_10_2013:BottomAdvancedTemplate
 
{{Top_10_2013:BottomAdvancedTemplate
     |type={{Top_10_2010:StyleTemplate}}
+
     |type=box
     |usenext=2013NextLink
+
    |useprev=2017PrevLink
 +
    |prev=A1-{{Top_10_2010:ByTheNumbers
 +
        |1
 +
        |year=2017
 +
        |language=en
 +
    }}
 +
     |usenext=2017NextLink
 
     |next=A3-{{Top_10_2010:ByTheNumbers
 
     |next=A3-{{Top_10_2010:ByTheNumbers
              |3
+
        |3
              |year=2017
+
        |year=2017
              |language=en}}
+
        |language=en
     |useprev=2013PrevLink
+
     }}
    |prev=A1-{{Top_10_2010:ByTheNumbers
 
              |1
 
              |year=2017
 
              |language=en}}
 
 
     |year=2017
 
     |year=2017
 
     |language=en
 
     |language=en
 
}}
 
}}
 +
 +
<!-- [[Category:OWASP Top Ten Project]] -->

Latest revision as of 16:24, 1 January 2018

← A1-Injection
2017 Table of Contents

PDF version

A3-Sensitive Data Exposure →
Threat Agents / Attack Vectors Security Weakness Impacts
App Specific Exploitability: 3
Prevalence: 2
Detectability: 2
Technical: 3
Business ?
Attackers have access to hundreds of millions of valid username and password combinations for credential stuffing, default administrative account lists, automated brute force, and dictionary attack tools. Session management attacks are well understood, particularly in relation to unexpired session tokens. The prevalence of broken authentication is widespread due to the design and implementation of most identity and access controls. Session management is the bedrock of authentication and access controls, and is present in all stateful applications.
Attackers can detect broken authentication using manual means and exploit them using automated tools with password lists and dictionary attacks.
Attackers have to gain access to only a few accounts, or just one admin account to compromise the system. Depending on the domain of the application, this may allow money laundering, social security fraud, and identity theft, or disclose legally protected highly sensitive information.
Is the Application Vulnerable?

Confirmation of the user's identity, authentication, and session management are critical to protect against authentication-related attacks. There may be authentication weaknesses if the application:

  • Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords.
  • Permits brute force or other automated attacks.
  • Permits default, weak, or well-known passwords, such as "Password1" or "admin/admin“.
  • Uses weak or ineffective credential recovery and forgot-password processes, such as "knowledge-based answers", which cannot be made safe.
  • Uses plain text, encrypted, or weakly hashed passwords (see A3:2017-Sensitive Data Exposure).
  • Has missing or ineffective multi-factor authentication.
  • Exposes Session IDs in the URL (e.g., URL rewriting).
  • Does not rotate Session IDs after successful login.
  • Does not properly invalidate Session IDs. User sessions or authentication tokens (particularly single sign-on (SSO) tokens) aren't properly invalidated during logout or a period of inactivity.
How to Prevent
  • Where possible, implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential re-use attacks.
  • Do not ship or deploy with any default credentials, particularly for admin users.
  • Implement weak-password checks, such as testing new or changed passwords against a list of the top 10000 worst passwords.
  • Align password length, complexity and rotation policies with NIST 800-63 B's guidelines in section 5.1.1 for Memorized Secrets or other modern, evidence based password policies.
  • Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes.
  • Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected.
  • Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session IDs should not be in the URL, be securely stored and invalidated after logout, idle, and absolute timeouts.
Example Attack Scenarios

Scenario #1: Credential stuffing, the use of lists of known passwords, is a common attack. If an application does not implement automated threat or credential stuffing protections, the application can be used as a password oracle to determine if the credentials are valid.

Scenario #2: Most authentication attacks occur due to the continued use of passwords as a sole factor. Once considered best practices, password rotation and complexity requirements are viewed as encouraging users to use, and reuse, weak passwords. Organizations are recommended to stop these practices per NIST 800-63 and use multi-factor authentication.

Scenario #3: Application session timeouts aren't set properly. A user uses a public computer to access an application. Instead of selecting “logout” the user simply closes the browser tab and walks away. An attacker uses the same browser an hour later, and the user is still authenticated.

References

OWASP

External

← A1-Injection
2017 Table of Contents

PDF version

A3-Sensitive Data Exposure →

© 2002-2017 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved. CC-by-sa-3 0-88x31.png