Home
Independent
Programming
  1. Software Standards Specification
  2. Software Requirements Definition
  3. Software Best Practices
  4. Input Validation
  5. Output Validation
  6. Cookie Requirements
  7. Access Failure Error Checking
  8. Buffer Overflow
  9. Code Structure
  10. Software Functions
  11. Software Modules
  12. Requirements for Variables
  13. Software Code Comment Requirements
  14. Quality Code Requirements
  15. Software Code Review
  16. Software Code Testing Requirements
  17. Software Change Control

    Security Best Practices

  18. Secure Functional Requirements
  19. Account Creation
  20. Change Password
  21. Forgot Password
  22. Personal Question
  23. Contact Webmaster
  24. CAPTCHA Tests
  25. Answer Verification
Programming
Independent
Home

Secure Functional Requirements

When writing software, there are some security best practices that are important to be aware of. These best practices include secure methods to perform certain capabilities such as creating accounts securely, performing password resets securely, contacting a webmaster, and other functional capabilities. Other capabilities that require consideration for best practices include web application controls, session management, data encryption, and interaction with other applications.

Secure software functional requirements include the following:

  • Sensitive Data Transmission
    • All sensitive data must be sent in encrypted form using the HTTPS protocol. Servers that untrusted users access must use signed certificates by a recognized public Certificate Authority.
    • When sensitive data is being sent between the user and the server on internet or intranet applications, sending HTML commands to tell the user browser not to cache pages with sensitive data or passwords using the following:
      • The <META HTTP-EQUIV="Pragma" CONTENT="no-cache"> command to tell the browser not to cache the page.
      • Use the HTML expires command to indicate the page is already expired which should tell the browser to delete the page.
  • Logon page - Security concerns - not caching, not allowing the back button and refresh (resend) of information.
    • Display an acceptable use statement on user logon page and password reset pages
    • The page must be treated as sensitive data and the browser must be told not to cache the page.
    • The logon page must use the password field to keep the password from being viewable.
    • Logon page requests and password recovery page requests must be submitted to the server using a POST request rather than a GET request so the page is not retained in the browser's history.
    • The logon page should redirect the user to a different page to authenticate then once authenticated, the user should be re-directed to a third page. The page settings of the page being authenticated should be set to expire so it cannot be reloaded using the back button on the browser. The login page should have the no-cache directive set to prevent storage of information in temporary folders.
    • The software must support account lockout for a set number of bad logon attempts. The software should allow an administrator reset or an automatic reset of the account after a configurable period of time. If an automatic reset option is allowed, an administrator should be emailed when accounts are automatically locked.
    • The system combined with the login page should require delays based upon the number of bad logon attempts in a row. The first bad login attempt should require a five second delay before the second. Each subsequent bad logon attempt should double the delay before the next and the user should be informed of the delay and when the next attempt can be made. The bad logon delay may be used as a substitute for account lockout which it essentially becomes once there are enough bad logins. However, once the delays are too long, the user would have no choice but to reset the password.
  • Logout
    • A logout process must be provided.
    • An automatic logout during session inactivity must occur.
  • Password security
    • Passwords are stored on the database as a secure hash and cannot be decoded.
    • All passwords during logon are transmitted from client to server as a salted hash, an encrypted hash, or an encrypted salted hash.
    • New passwords sent from the client to server during password changing, password resetting, or initial account setup shall be encrypted using an asymmetric public key algorithm.
    • Password changing must be on its own page without the ability to change other user settings on the same page.
    • Password changing must require the entry and correct validation of the current password and two fields for the new password to make sure the user typed the new password correctly. All passwords must be properly encrypted (for the new passwords) and hashed (for the current password).
    • The software must support a password/passphrase length of at least 127 two byte characters.
    • The software must support minimum complexity rules for passwords.
    • The software must support configurable account lockout based on the number of failed logon attempts in order to prevent a dictionary attack or brute force attack against the account. Locked accounts may be unlocked after 30 minutes or more (24 hours) of inactivity or reset by an administrator.
  • Password reset - The password reset page must utilize the same requirements as the account logon page.
    • Password reset must consider all items required for password security.
    • Use of secret questions can be a security concern. This and a possibly more secure password reset method is discussed on the password reset page.
  • Account creation
    • The password entry page portion of account creation must be separate from the parts of the account creation page that contain personal data including a secret question.
    • If a password is created, it shall be encrypted using an asymmetric public key algorithm.
    • Account creation must consider all items required for password security.
  • Contacting the webmaster - Pages used to contact the webmaster must be secured from abusive actions. Specifically pages allowing a user to fill out a page and send some text to the webmaster must be properly secured. The input must be filtered against email injection as described in the "Input Validation" page.
  • Submitting information to a website - The website submission form must be filtered against injectionof harmful content that could be used to attack computers owned by those who view those pages later.
  • Preventing spamming of website submission - Spamming of web site submission can be prevented either by using CAPTCHA testing to stop robotic submissions or through the use of user accounts that are tied to validated email addresses.