Add some tips about handling I&A, esp. passwords

The tip about enabling copying text into password fields
was inspired by Kurt Seifried.

Signed-off-by: David A. Wheeler <[email protected]>

Author: david-a-wheeler

secure_software_development_fundamentals.md

@@ -1776,17 +1776,24 @@ If your program allows uploads, try to limit uploads to specific file types and
 
 ( ) False
 
-### Minimizing Attack Surface, Authentication, and Authorization
+### Minimizing Attack Surface, Identification, Authentication, and Authorization
 
 In the Design chapter (in Part I of this course), we noted that it is important to minimize the *attack surface* - that is, the interfaces the attacker can get access to. This does not mean “limit the interfaces that you *intend* for users to use"; your *implementation* must limit the interfaces an attacker has access to. Try to make it so attackers cannot even *access* most interfaces, then carefully protect the interfaces that are accessible.
 
-That said, in many systems, attackers will be able to attempt some requests. In those cases, you will need to make sure that the request is authorized before it is honored. Remember, authorization means determining whether or not that request is allowed to that person or program.
+That said, in many systems, attackers will be able to attempt some requests. In those cases, you will need to make sure that the request is authorized (allowed) before it is honored. Remember, authorization means determining whether or not that request is allowed to that person or program.
 
-You need to check whether or not a request is authorized in absolutely every case. That is to say, ensure that authorization checks are non-bypassable. Tools are often not good at determining if every request is checked for authorization, so you typically need to depend primarily on human review. If humans can easily see that the correct authorization check is made for every request, it takes much less time to review *and* it is more likely to be correct. In practice, that often means that programs should check for authorization as soon as you reasonably can do so. Exactly what that means depends on your system, e.g., in a model-view-controller architecture, you could put authorization checks on each controller entry and/or each model entry. What matters is that you do it consistently and that it is easy for others to verify that it cannot be bypassed. Similarly, the data needs to be stored so that only authorized requests can succeed.
+You need to *check* whether or not a request is *authorized* in *absolutely every case* if it might not be. That is to say, ensure that authorization checks are non-bypassable. Tools are often not good at determining if every request is checked for authorization, so you typically need to depend primarily on human review. If humans can easily see that the correct authorization check is made for every request, it takes much less time to review *and* it is more likely to be correct. In practice, that often means that programs should check for authorization as soon as you reasonably can do so. Exactly what that means depends on your system, e.g., in a model-view-controller architecture, you could put authorization checks on each controller entry and/or each model entry. What matters is that you do it consistently and that it is easy for others to verify that it cannot be bypassed. Similarly, the data needs to be stored so that only authorized requests can succeed.
 
 🔔 Inadequate authorization is such a common mistake that *Broken Access Control* is 2017 OWASP Top 10 #5 and 2021 OWASP Top 10 #1. *Incorrect Authorization* is 2021 CWE Top 25 #38 and 2019 CWE Top 25 #33 ([CWE-863](https://cwe.mitre.org/data/definitions/863.html)), and *Missing Authorization* is 2021 CWE Top 25 #18 and 2019 CWE Top 25 #34 ([CWE-862](https://cwe.mitre.org/data/definitions/862.html)).
 
-Of course, if something requires authorization, that means there should first have been some kind of authentication to ensure that the request was from whom they claimed to be. Thoroughly check how you handle authentication, and where practical, use well-respected services, libraries, or frameworks to do it.
+Of course, if something requires authorization, that means there should first have been some kind of identification and authentication (I&A) to ensure that the request was from whom they claimed to be. Thoroughly check how you handle authentication, and where practical, use well-respected services, libraries, or frameworks to do it.
+
+You should typically first do input validation of an identity (such as a username or email address), before doing anything else with it, to reduce the likelihood of an attacker subverting a system through its login system. In most cases you should only report “login failed” (or similar) if the combination of identity and authentication failed; don’t reveal if the identity exists in the system, since that lets the attacker know if the identity is present on the system. You should support multi-factor authentication (MFA) logins, either directly or via a service, since these tend to be stronger than passwords.
+
+If you do support passwords for authentication, follow good practices, e.g.:
+1. Make sure that no more than 1 character of a password is displayed to a user at a time, to reduce the risk of someone else being able to see the password (aka “shoulder surfing”). You can do this in HTML input fields by using the input type `password`.
+2. Ensure that users can use password managers. For example, ensure that users can copy text into the password fields, as this functionality is necessary for some password managers.
+3. When changing a password, ask the user to enter the old password or require an out-of-band I&A evidence (this prevents an attacker from changing the password if they have very brief control of the account). Also, ask the user to enter a new password twice and verify that they are the same, to ensure that the intended password will be used as the password.
 
 🔔 2021 OWASP Top 10 #7 is *Identification and Authentication Failures*. Inadequate authentication is such a common mistake that *Broken Authentication* is 2017 OWASP Top 10 #2, 2021 CWE Top 25 #14, and 2019 CWE Top 25 #13. It is [CWE-287](https://cwe.mitre.org/data/definitions/287.html), *Improper Authentication*. *Missing Authentication for (specifically a) Critical Function* is 2021 CWE Top 25 #11 and 2019 CWE Top 25 #36 ([CWE-306](https://cwe.mitre.org/data/definitions/306.html)).