refactor(API2:2019): rename

API2:2019 was renamed Broken User Authentication to avoid
misunderstandigs with client <-> api server authentication.

Author: PauloASilva

2019/en/dist/owasp-api-security-top-10.odt

@@ -9,7 +9,7 @@ Table of Contents
 * [API Security Risks](0x10-api-security-risks.md)
 * [OWASP Top 10 API Security Risks – 2019](0x11-t10.md)
 * [API1:2019 Broken Object Level Authorization](0xa1-broken-object-level-authorization.md)
-* [API2:2019 Broken Authentication](0xa2-broken-authentication.md)
+* [API2:2019 Broken User Authentication](0xa2-broken-user-authentication.md)
 * [API3:2019 Excessive Data Exposure](0xa3-excessive-data-exposure.md)
 * [API4:2019 Lack of Resources & Rate Limiting](0xa4-lack-of-resources-and-rate-limiting.md)
 * [API5:2019 Broken Function Level Authorization](0xa5-broken-function-level-authorization.md)

2019/en/dist/owasp-api-security-top-10.pdf

@@ -4,7 +4,7 @@ OWASP Top 10 API Security Risks – 2019
 | Risk | Description |
 | ---- | ----------- |
 | API1:2019 - Broken Object Level Authorization | APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user. |
-| API2:2019 - Broken Authentication | Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Compromising system's ability to identify the client/user, compromises API security overall. |
+| API2:2019 - Broken User Authentication | Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Compromising system's ability to identify the client/user, compromises API security overall. |
 | API3:2019 - Excessive Data Exposure | Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user. Without controlling the client's state, servers receive more-and-more filters which can be abused to gain access to sensitive data. |
 | API4:2019 - Lack of Resources & Rate Limiting | Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force. |
 | API5:2019 - Broken Function Level Authorization | Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions. |

2019/en/src/0x00-toc.md

@@ -1,5 +1,5 @@
-API2:2019 Broken Authentication
-===============================
+API2:2019 Broken User Authentication
+====================================
 
 | Threat agents/Attack vectors | Security Weakness | Impacts |
 | - | - | - |
@@ -24,8 +24,6 @@ An API is vulnerable if it:
 * Accepts unsigned / weakly signed JWT tokens (`"alg":"none"`) / doesn’t
   validate their expiration date.
 * Uses plain text, encrypted, or weakly hashed passwords.
-* Uses weak encryption keys / API keys.
-
 
 ## Example Attack Scenarios