You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: secure_software_development_fundamentals.md
+6-4Lines changed: 6 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1788,20 +1788,22 @@ You need to *check* whether or not a request is *authorized* in *absolutely ever
1788
1788
1789
1789
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.
1790
1790
1791
-
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.
1791
+
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 the identity and the authentication (such as a password) 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.
1792
1792
1793
1793
If you do support passwords for authentication, follow good practices, e.g.:
1794
1794
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`.
1795
-
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.
1796
-
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.
1795
+
2. Ensure that users can use password managers when logging in, creating a password, or changing a password. For example, ensure that users can copy text into the password fields, as this functionality is necessary for some password managers. Forcing users to manually type passwords encourages them to use poor passwords and discourages them from using a password manager (which is considered best practice by many).
1796
+
3. When creating or changing a password, ask the user to enter the old password. This prevents an attacker from easily changing the password if they have 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. This also verifies that a password manager (if any) is sending the password consistently.
1797
+
1798
+
When a user changes a password or other credential (like MFA tokens), consider notifying the user (such as by sending an email or text message). That way, if the user didn’t cause the change, the user will be immediately alerted.
1797
1799
1798
1800
🔔 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)).
1799
1801
1800
1802
We will later discuss various tools for verification. While tools can help find some problems, they are often *less* effective at finding authentication and authorization problems, because the tools don’t usually have enough information to determine *what is acceptable* and *what is not*. It helps to have tests that verify unauthorized requests are rejected, of course. But the most effective approach is ensuring that absolutely every input path is quickly authenticated and authorized where appropriate, so that manual review can easily assure reviewers that all cases are covered.
1801
1803
1802
1804
> 😱 STORY TIME: Target Breach
1803
1805
1804
-
> In 2013 the Target Corporation’s network was breached. In this incidence 40 million credit and debit card numbers and 70 million records of personal information were stolen. The full costs are difficult to estimate, but the credit card unions spent over $200 million just to reissue cards. The best available evidence suggests that the initial breach occurred in a third party heating, ventilation, and air-conditioning (HVAC) firm. The attackers used these compromised credentials to penetrate the Target network. The attackers were able to subvert sensitive systems due to the weak segmentation between non-sensitive and sensitive networks inside Target ([*Breaking the Target: An Analysis of Target Data Breach and Lessons Learned*](https://arxiv.org/pdf/1701.04940.pdf), by Xiaokui Shu, Andrew Ciambrone and Danfeng Yao, 2017).
1806
+
> In 2013 the Target Corporation’s network was breached. In this incident 40 million credit and debit card numbers and 70 million records of personal information were stolen. The full costs are difficult to estimate, but the credit card unions spent over $200 million just to reissue cards. The best available evidence suggests that the initial breach occurred in a third party heating, ventilation, and air-conditioning (HVAC) firm. The attackers used these compromised credentials to penetrate the Target network. The attackers were able to subvert sensitive systems due to the weak segmentation between non-sensitive and sensitive networks inside Target ([*Breaking the Target: An Analysis of Target Data Breach and Lessons Learned*](https://arxiv.org/pdf/1701.04940.pdf), by Xiaokui Shu, Andrew Ciambrone and Danfeng Yao, 2017).
0 commit comments