Keeping the theme from last post, let us dig into how system designers can take advantage of simple technology agnostic and common security best practices to design a sound user and password management subsystem for their critical IT applications.
Best Practice Area
Security Best Practices
Password Policy Definition and Management
Applications should implement a sound password policy that meets business needs while assuming a defense in depth strategy.
All passwords (initial password, reset password, user changed password) must comply with password policies of the organization. This includes passwords for users, administrators, database access, operating systems, and any other services.
For example, a simple password policy states that passwords must be based on the 7-bit ASCII character set. Password complexity must be at least 7 characters in length, and have at least one uppercase letter, one lowercase letter, and one number.
In addition to standard password length and complexity controls, application should enforce controls that prevent users for setting passwords identical to their username, name, or other similar data elements.
Initial or default passwords should be generated using a cryptographically secure random string generation process. Initial or default passwords should be generated using a cryptographically secure random string generation process.
Applications should enforce a password-aging policy that accommodates business needs.
For example, a simple policy may state that user passwords must be changed every 90 days, and administrator passwords must be changed every 45 days.
Applications should not allow previous passwords to be re-used when enforcing password aging policies.
For example, at-least 3 previous passwords may be stored as password history and not allowed to be re-used by the user.
Credential Display, Storage, and Transmission
Passwords should be stored as hashed values. The hash method used must implement a salting mechanism. If passwords are not stored as hashed values, they must be stored using another approved secure method. This applies to currently active passwords and any password histories maintained by the application.
Initial or temporary passwords should be transmitted to the user through a secure means that cannot be easily intercepted.
For example, using secure email
No un-authenticated or un-authorized user should be allowed to verify if a given username and or password is valid or not.
This includes all login pages, password hint pages, password reset pages, and other pages that accept a username or other user related data as input.
For example, the application should abstract the cause of the error by providing generic error messages instead of revealing the exact error.
Further, the application must not reveal a list of users or accounts to an authenticated user unless there is a legitimate business need.
User Registration and Management
Applications should use a secure directory service for user account management (authentication, authorization, identity, etc). If an application is not integrated with an approved directory service, it must implement its own user account management module.
Every user must have a unique account to access the application. This will ensure the accountability for individual user and reduce the possibility of account information re-use.
User self-registration should follow a two-step validation process, with the first step being identification. If using a two-step validation, the second step must be returning to the site with a time sensitive temporary password sent to the identified user’s address.
If the application uses a registration process that validates a user against a list of authorized users, the registration process must ensure the user cannot register more than once.
When a user receives either an initial or temporary password resulting from an online password reset or administrator-assisted password reset, the user must be required to change their password upon next login.
It is especially critical to force password changes if the initial or temporary password was at the risk of un-authorized disclosure, such as when sent through unencrypted e-mail.
To prevent brute-force attacks on user credentials, an account lockout policy must be implemented.
Password Change Management
Application design must allow for an authenticated user to change his/her current password
All password changes should trigger an e-mail notification to the e-mail address on record. This includes elective password changes, forced password changes, and either administrative or system initiated password resets. Such notification serves both as confirmation and early warning of possible account break-in or unauthorized use.
All methods of password resets should be documented, approved, documented and secure by design.
For example, items that may be included in these reset methods are:
The notification method describing how users request a password reset. The process through which administrators verify the requestor's identity. The process through which administrators fulfill the password reset request. The process through which passwords are securely transmitted to the user.
During a password change, the application must validate the user’s current password. This reduces the possibility of an attacker forcing a password change without authorization.
During a password change, the application must force the user to enter the new password twice. This method reduces typographical errors when entering new passwords.
When a user requests a new password, the new password must not be a default password or a password that is manually assigned by the administrator.
Using system generated passwords helps prevent an attacker from requesting a password reset on behalf of the victim and thereby gaining access to the victim's account using known default passwords.
The new or reset password should have a limited life-span in order to reduce the duration of exposure.
The above guidance is not comprehensive but attempts to outline the best practices to achieve functional requirements of a user and password management subsystem.
Ashish Popli, Sr. Security Consultant, Microsoft ACE Services.
PingBack from http://msdnrss.thecoderblogs.com/2007/08/16/application-security-guidance-user-and-password-management/