Difference between revisions of "OWASP Common Numbering Project"

Jump to: navigation, search
(One intermediate revision by one other user not shown)
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">
Line 10: Line 20:
==== OWASP Common Requirements Numbering Scheme====
==== OWASP Common Requirements Numbering Scheme DRAFT====
<table width="100%" valign="top"><tr><th width="50%"> </th><th> </th></tr><tr valign="top">
<table width="100%" valign="top"><tr><th width="50%"> </th><th> </th></tr><tr valign="top">
<td>'''Proposed OWASP Common Requirements Numbering Scheme Format:'''
<td>'''Proposed OWASP Common Requirements Numbering Scheme Format:'''

Latest revision as of 11:02, 17 April 2014

OWASP Inactive Banner.jpg


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:

Common Requirements Numbering Scheme Proposed Requirement Areas:

  • OCR-AUTHN: Authentication
  • OCR-SESS: Session Management
  • OCR-INPVAL: Input Validation
  • OCR-OUTENC: Output Encoding
  • OCR-AUTHZ: Functional and Data Layer Access Control
  • OCR-BUS: Business Logic
  • OCR-DATAP: Sensitive Data Protection
  • OCR-CRYPST: Cryptographic Storage
  • OCR-COMMS: Communication Security
  • OCR-ERROR: Error Handling
  • OCR-LOG: Logging
  • OCR-DBASE: Secure Database Usage
  • OCR-FILE: Secure File Access
  • OCR-MEM: Memory Management
  • OCR-GEN: General Coding Practices
  • OCR-CONFIG: Secure System Configuration
  • OCR-INTEG: Integrity
  • OCR-AVAIL: Availability
  • 1st Element - Document code (OCR=OWASP Common Requirements Number, ODG=OWASP Development Guide, OTG=OWASP Testing Guide, OCG=OWASP Code Review Guide, others reserved)
  • 2nd Element - Requirement Area (major)
  • 3rd Element - Detailed Requirement Identifier (minor with up to one sublevel (e.g., .01, .02)
  • 4th Element (Optional: DEPRECATED, or # for iterations, or legacy identifiers)

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.

OWASP Common Number
Common Requirement
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

What does this OWASP project offer you?
What releases are available for this project?
what is this project?
Name: OWASP Common Numbering Project (home page)
Purpose: An exciting development, a new numbering scheme that will be common across OWASP Guides and References is being developed. The numbering is loosely based on the OWASP ASVS section and detailed requirement numbering. OWASP ASVS, Guide, and Reference project leads and contributors as well as the OWASP leadership plan to work together to develop numbering that would allow for easy mapping between OWASP Guides and References, and that would allow for a period of transition as Guides and References are updated to reflect the new numbering. This project will provide a centralized clearinghouse for mapping information.
License: Creative Commons Attribution ShareAlike 3.0 license
who is working on this project?
Project Leader(s):
Project Contributor(s):
how can you learn more?
Project Pamphlet: Not Yet Created
Project Presentation:
Mailing list: Mailing List Archives
Project Roadmap: View
Key Contacts
  • Contact the GPC to report a problem or concern about this project or to update information.
current release
Not Yet Published
last reviewed release
Not Yet Reviewed

other releases