Application Security Guidelines for Web Application.

1. Authentication process should not be bypassed.
2. User names should be unique.
3. All user names should be unpredictable. It should not be possible to guess the user name.
4. Email addresses should not be allowed as usernames if email is one of the password reset options.
5.  If user name and/or password or both are incorrect then a generic error message such as “Username and/or password are invalid” should be given
6. Self registration of usernames is optional. If self registration is unavailable to new users, then the application doesn’t need to disclose whether or not a selected username already exists
7. Password Lockout

Ø      Ensure that the users account is locked out    for a period of time when the incorrect password is entered more that a specific number of times (usually 5).

Ø      Account holder should not be notified that any specific account has been locked   out. Account holder should be advised to phone customer support and/or answer a series of security questions for successful login.

Ø      If a locked out account attempts to login, it should be rejected immediately without checking credentials.

Ø      Captcha can be implemented to stop automated cracking of login passwords.

8. Password Lockout (Extended)

Ø      Password suspension should be enforced and accounts should not be locked out (preventing attackers the ability to deny access to legitimate users).

Ø      Account holder should not be notified that any specific account has been suspended. All failed login attempts (including invalid username) should respond with the same generic message, “Accounts are suspended if multiple login failures occur. If you believe that your account has been suspended, please try again later”.

Ø       If any suspended account attempts to login, it should be rejected immediately without checking credentials.      <Suggestions: Exponential time suspension after second bad attempt. For example, after two password tries – 5 minutes, three password tries – 10 minutes, etc>

9. Blank password should not be allowed
10. Password should not be same as username or any common word
11. Password should be between 8 to 40 Characters and should contain a special character like (! @#$%^&*()). Password should use both small and capital letter and numerals.
12. Password should be changed periodically. Suggested to change every 30 days
13.  Users should be required to choose fresh passwords when changing them to avoid cycling though easily guessable or common passwords.
14. All passwords should be unpredictable. If initial passwords are chosen for the user before they are able to pick their own password then the password must be unpredictable. (Suggestions: 16-character random password, etc)
15. Session token length should be adequate to provide protection from guessing during an authenticated session.
16. Session token should be valid for a predetermined period after the last request by the user. Provide session timeout e.g 20 minutes. The application should make this actionable in the same way as if the user had logged out of the application.
17.  All session tokens issued after authentication must only be sent over SSL
18. Session tokens should be changed when the user moves from an SSL protected resource to a non- SSL protected resource
19. All session tokens should be created so they could not be reused on a host other than the one it was issued to.
20. Session token should be invalidated when the user logs out.
21. Session token should be non-persistent and should never be written to the browsers history or cache.
22. The application should display an approved, system use notification message before granting access, informing potential users
23. The application should notify the user, upon successful logon, of the date and time of the last logon, and the number of unsuccessful logon attempts since the last successful logon.
24. The application must limit the number of concurrent sessions for any user to [defined number of sessions].

            (Each technology will have different "session" limitations this is different to server concurrent connections.)

25. All user account management activity including account maintenance, and password resets should take place using 256 bit SSL (with valid certificates).
26. Application should be capable of logging successful and unsuccessful logging attempts
27. All data being accepted from users, or other systems should be validated to ensure that it is of the correct type, of an expected length, of the correct syntax including having no illegal characters, and if numerical of the correct range. Only data with expected characteristics should be processed.
28. All input should be encoded into a normalized form before being processed
29. All data being processed should be validated to ensure that it is of the correct type, of an expected length, of the correct syntax including having no illegal characters, and if numerical of the correct range. Only data with expected characteristics should be processed.
30. All output should be encoded into a normalized form before being processed
31. Database Server & Application server should be in different network zone implemented through Firewall zone.
32. Application should not present application error messages to an attacker that could be used in an attack.