We have chosen to discuss on this topic not because many other websites have talked on the same, but because this is very important when you consider designing an application or framework that involves password based authentication. Just like how important it is to store and implement certain constraints and compliances to credit card information storage system, you need to consider password implementation with atmost importance. There are several topics in our Password Analytics that discuss about the same. We would like to define a generic password protected software as:
"A software or application that uses password in combination with a user name or a unique identifier that allows us to know what the user is authenticating to and the type of access given to this user."
That being the case, we would like to ensure that the password protected software is designed in such a way that there are no vulnerabilities in the design and implementation of the password protection itself. Some of the design and implementation constraints include [and is not limited to]:
Ensure that adequate strength testing and analysis mechanisms are in place to ensure that the passwords aren't weak enough to be cracked by the attacker within the age of the password, which is implemented by password longevity.
Never reveal users passwords on the screen, be it typed or stored passwords. This would ensure that no one other than the users would know the password. If the user wants to reset his or her password, the only way is to go through a series of steps to authenticate themselves to be whom they say they are, through email or phone and then give them the replacement passwords and not by displaying it on the screen.
Force users to frequently change their passwords. If the user has not signed in for a while, force the user to change his or her password at their first sign on. Fix a password longevity policy and enforce it using automated password change system.
Users accounts being attempted for sign on over 3-5 attempts (or any other fixed number of times), as enforced by the policy should be locked at all times. Only a system or a network admin should then unlock access to the user account that has been locked. By doing this, one could prevent user accounts from being targeted by automated bruteforcing or scripted password attacks.
Users that leave the password based autentication system or software open for a while (in idle state) should be forced to re-login into their account to ensure that an attacker with physical access to the secure location does not misuse the user's system with their privileges.
This would ensure that the users are given strong password right from the beginning. Once a user is given a random password, be it the first time when the user login or when the user forgot the password and is given an alternate random password, a mechanism should be put in place to determine if this is a randomly generated password that forces the user to change the password from the initial random password to one of his or her own passwords.
Sending passwords in plain text over wire would only increase the chances of getting snooped and sharing privileges with the attackers. Sending passwords over encrypted channels would reduce the chances of loosing your password to the attacker, unless you loose it through MITM(Man/Monkey-in-the-middle) attack, where you are unknowingly accepting the attacker's certificate assuming that it is the domain's certificate that you wanted to visit.
For more information on password security content and constraints, check out Federal Information Processing Standards (FIPS), NIST or other standards that help you set and follow a specific guidelines to protect your enterprise from targeted attacks. Compliance, policies, guidelines or standards should not be in the papers (paperwork) alone. They should be enforced right from the very beginning and even if not from the beginning, you should try and make it as the integral part of the system.