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 "OWASP Common Numbering Project"
From OWASP
m |
|||
| Line 1: | Line 1: | ||
| + | {| | ||
| + | |- | ||
| + | ! width="700" align="center" | <br> | ||
| + | ! width="500" align="center" | <br> | ||
| + | |- | ||
| + | | align="right" | [[Image:OWASP Inactive Banner.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]] | ||
| + | | align="right" | | ||
| + | |||
| + | |} | ||
| + | |||
==== Home ==== | ==== Home ==== | ||
<table width="100%" valign="top"><tr><th width="100%"> </th><th> </th></tr><tr valign="top"> | <table width="100%" valign="top"><tr><th width="100%"> </th><th> </th></tr><tr valign="top"> | ||
Latest revision as of 16:02, 17 April 2014
| |
|
|---|---|
|
Home
| Common OWASP Numbering
An exciting development, a new numbering scheme that will be common across various OWASP Guides and References is being developed. This numbering scheme is loosely based on the OWASP ASVS section and detailed requirements numbering. The OWASP ASVS, Guide, and Reference project leads and contributors plan to work together to develop a numbering scheme that facilitates easier mapping between various OWASP Guides and References, and that would allow for a period of transition as the Guides and References are updated to reflect the new numbering scheme. This project will provide a centralized clearinghouse for mapping information. For more information on this project, or if you wish to contribute, please contact Dave Wichers. This common numbering scheme will be of requirements. A mapping of vulnerabilities to this requirements list will most likely be developed after the common requirements list is created. This common numbering scheme is intended to be independent of any particular OWASP project and is not intended to dictate how those projects are developed and organized. Its intent is to be a resource to facilitate cross referencing between related topics and to encourage, but not require, projects like the OWASP Guides to adopt a similar structure. But that decision is up to the respective project leads. |
OWASP Common Requirements Numbering Scheme DRAFT
Proposed OWASP Common Requirements Numbering Scheme Format:
OCR-AUTHN-01 OCR-AUTHN-02 OCR-AUTHN-02.01 OCR-AUTHN-03 OCR-INPVAL-01 OCR-INPVAL-02 Common Requirements Numbering Scheme Proposed Requirement Areas:
|
Reference
|
OWASP Common Requirements - DRAFT
The following is the first section we have developed of common requirements. It is the section on Authentication (OCR-AUTHN). This is draft, and your feedback is very welcome. Please provide any feedback to Dave Wichers.
| |
|
| Authentication Requirements | |
| OCR-AUTH-01 | All authentication controls operate on a trusted system (e.g., The server). |
| OCR-AUTH-02 | Authentication is required for all pages and resources, except those specifically intended to be public. |
| OCR-AUTH-03 | The application utilizes standardized, tested, and centralized authentication services. |
| OCR-AUTH-04 | Authentication services utilize a centralized authentication store. |
| OCR-AUTH-05 | All authentication controls fail securely. |
| OCR-AUTH-06 | System configurable password strength requirements are enforced. This includes both minimum length and minimum complexity rules. |
| OCR-AUTH-07 | Disallow account passwords to match any of the last N passwords for that account, where N is a system configurable value. This is done to discourage password re-use. |
| OCR-AUTH-08 | Passwords must be a system configurable minimum age (e.g., one day old) before they can be changed, to prevent attacks on password re-use |
| OCR-AUTH-09 | Password entry fields do not echo the user’s password when it is entered. |
| OCR-AUTH-10 | Autocomplete is disabled for all password entry fields in HTML forms. |
| OCR-AUTH-11 | Passwords are transmitted over an encrypted connection. Temporary passwords associated with email resets may be an exception to this rule. |
| OCR-AUTH-12 | For authentication over HTTP, authentication credentials are transmitted only within the POST body and not in the URL. |
| OCR-AUTH-13 | Authentication controls and application functionality minimize the leakage of user account names. |
| OCR-AUTH-14 | Stored server side passwords are protected using cryptographically strong one-way salted hashes that use salts that are unique per account. (e.g., Do not use the MD5 or SHA-1 algorithms). |
| OCR-AUTH-15 | Use large numbers of hash iterations or password based encryption to make it time consuming to calculate a single hashed password value. |
| OCR-AUTH-16 | Stored passwords and cryptographic keys are readable and writeable only by the application. |
| OCR-AUTH-17 | Brute force protection is provided after a system configurable number of invalid login attempts occur against an account within a configurable period of time (e.g., account is locked, CAPTCHA required, throttling enabled). |
| OCR-AUTH-18 | Implement monitoring to identify attacks against multiple user accounts, utilizing the same password. This attack pattern is used to bypass standard lockouts, when valid user IDs can be harvested or inferred. |
| OCR-AUTH-19 | The date/time of the last successful login is reported to the user after they login, along with the number of failed login attempts since the last successful login. |
| OCR-AUTH-20 | Password changing mechanisms are at least as resistant to attack as the primary authentication mechanism. |
| OCR-AUTH-21 | Passwords are required to be changed before they become older than a system configurable maximum age. |
| OCR-AUTH-22 | Password reset questions support sufficiently random answers. (e.g., "favorite color" is a bad question because red, blue, green, are very common answers. Favorite book is another bad question that generates insufficiently random answers.). |
| OCR-AUTH-23 | For email based resets, only send email to a pre-registered address with a temporary link/password. Reset questions should be asked after the user goes to the temporary page, not before the email is generated. |
| OCR-AUTH-24 | Temporary passwords and links have a short, system configurable, expiration time. |
| OCR-AUTH-25 | Users are required to change temporary passwords as soon as they are used. |
| OCR-AUTH-26 | Users are notified when a password reset occurs on their account. |
| OCR-AUTH-27 | Users must re-authenticate prior to performing security critical operations, such as change password, change email address, change mailing address, change mailing address, view very sensitive data, send funds, etc. |
| OCR-AUTH-28 | All administrative and account management functions are at least as secure as the primary authentication mechanism. |
| OCR-AUTH-29 | Authentication is required for services exposed to external systems that provide sensitive information or functions. |
| OCR-AUTH-30 | All authentication credentials for accessing services external to the application are encrypted and stored in a protected location (e.g., not in source code). |
| OCR-AUTH-31 | Multi-Factor Authentication is used for highly sensitive or high value systems or for specific high value transactions. |
Project About
| PROJECT INFO What does this OWASP project offer you? |
RELEASE(S) INFO What releases are available for this project? | |||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| |||||||||||||||||||||||||||||||||||||
