Authentication, Authorization, Authentication… some say passwords have failed. They may be right, but passwords are still here. Software developers should expect users to select strong passwords and likewise, software users expect their data (including passwords) to be stored securely by software vendors. There never seems to be a wrong time to talk about this considering the almost constant trend of data breaches.
Here are 8 basic rules for handing passwords securely:
- Provide Brute Force Protection at Authentication Points: This defeats attackers who try to repeatedly guess and try passwords using automation.
- Hash All Passwords in Storage: Passwords must be stored in such a way that if the system is breached, their value cannot be discovered. PBKDF2 is an algorithm that is the default recommended for securely storing passwords; it requires as input a hashing algorithm, a number of iterations, a salt and a password. NIST’s recommendations are to use PBKDF2 with 10,000 iteration and at least a 32 bit salt produced by a secure random number generator
- Enforce or Provide Mechanisms for Strong Passwords Selection: ‘Strong’ is often based on a company’s policies but at least you can (or help admins to) prevent your users from selecting ‘password123’. NIST recommends a minimum password length of 8 characters for regular user accounts and a minimum of 14 characters for admin accounts.
- Validate Passwords Against a Dictionary Before Accepting: Passwords should not be allowed if they are commonly found in dictionaries used by hackers or based on such with minor modifications commonly used. Cracking tools will attempt multiple iterations on common password strings: password, Password, Password0, Passw0rd.
- On Failed Login, Do Not Disclose Username or Password Failure: Error messages should be generic to avoid user enumeration.
- Out of Band Authentication for Password Reset: Require some sort of second factor, such as an out of band SMS message to a phone, before sending a password change request email.
- Re-authenticate users prior to password changes/ updates: Before allowing password updates, the application should re-authenticate the user.
- Avoid Hard coded secrets: Apps must not have any hardcoded secrets (passwords, credentials, private keys, hidden commands) in the compiled code or source code.
Much thanks and a shout out to my colleague and friend, Antonio Martin, for helping to put the crux of this list together.
