fix(A2:2019): add references

* fix markdown
* add references

Author: PauloASilva

2019/en/src/0xa2-broken-authentication.md

@@ -8,17 +8,21 @@ A2:2019 Broken Authentication
 
 ## Is the API Vulnerable?
 
-Authentication endpoints and flows are assets that need to be protected.
-
-“Forgot password / reset passwords” should be treated the same way as authentication mechanisms.
-
-An API is vulnerable if: 
-* Permits [credential stuffing][1] where the attacker has a list of valid usernames and passwords.
-* Permits attackers to perform a brute force attack on the same user, without presenting captcha \ account lockout mechanism
+Authentication endpoints and flows are assets that need to be protected. “Forgot
+password / reset passwords” should be treated the same way as authentication
+mechanisms.
+
+An API is vulnerable if:
+* Permits [credential stuffing][1] where the attacker has a list of valid
+  usernames and passwords.
+* Permits attackers to perform a brute force attack on the same user, without
+  presenting captcha \ account lockout mechanism
 * Permits weak passwords
-* Sends sensitive authentication details, such as auth tokens and password in the URL.
+* Sends sensitive authentication details, such as auth tokens and password in
+  the URL.
 * Doesn’t validate the authenticity of tokens
-* Accepts unsigned / weakly signed JWT tokens ("alg":"none") / doesn’t validate their expiration date 
+* 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
 
@@ -27,10 +31,10 @@ An API is vulnerable if:
 
 ## Scenario #1
 
-[Credential stuffing][1], the use of [lists of known passwords][2], 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. 
+[Credential stuffing][1], the use of [lists of known passwords][2], 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
 
@@ -44,28 +48,42 @@ within a few minutes.
 
 ## How To Prevent
 
-* Make sure you know all the possible flows to authenticate to the API (mobile/web/deep links that implement one-click authentication/etc)
+* Make sure you know all the possible flows to authenticate to the API (mobile/
+  web/deep links that implement one-click authentication/etc)
 * Ask your engineers what flows you missed.
-* Read about your authentication mechanisms. Make sure you understand what and how they are used. OAuth is not authentication, and neither API keys .
-* Don't reinvent the wheel in authentication, token generation, password storage. Use the standards.
-* Credential recovery / forget password endpoints should be treated as login endpoints in terms of brute force, rate limiting and lockout protections.
+* Read about your authentication mechanisms. Make sure you understand what and
+  how they are used. OAuth is not authentication, and neither API keys .
+* Don't reinvent the wheel in authentication, token generation, password
+  storage. Use the standards.
+* Credential recovery / forget password endpoints should be treated as login
+  endpoints in terms of brute force, rate limiting and lockout protections.
 * Use the [OWASP Authentication Cheatsheet][3]
 * Where possible, implement multi-factor authentication.
-* Implement anti brute force mechanisms to mitigate credential stuffing, dictionary attack and brute force attacks on your authentication endpoints. This mechanism should be  stricter than the regular rate limiting mechanism on your API.
-* Implement [account lockout][4] / captcha mechanism to prevent brute force against specific users. 
-Implement weak-password checks.
-* API keys should not be used for user authentication, but for [client app / project authentication][5]. 
+* Implement anti brute force mechanisms to mitigate credential stuffing,
+  dictionary attack and brute force attacks on your authentication endpoints.
+  This mechanism should be  stricter than the regular rate limiting mechanism on
+  your API.
+* Implement [account lockout][4] / captcha mechanism to prevent brute force
+  against specific users. Implement weak-password checks.
+* API keys should not be used for user authentication, but for [client app /
+  project authentication][5].
 
 ## References
 
 ### OWASP
 
+* [OWASP Key Management Cheat Sheet][6]
 * [OWASP Authentication Cheatsheet][3]
 * [Credential Stuffing][1]
 
+### External
+
+* [CWE-798: Use of Hard-coded Credentials][7]
 
 [1]: https://www.owasp.org/index.php/Credential_stuffing
 [2]: https://github.com/danielmiessler/SecLists
 [3]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
 [4]: https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003)
 [5]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key
+[6]: https://www.owasp.org/index.php/Key_Management_Cheat_Sheet
+[7]: https://cwe.mitre.org/data/definitions/798.html