During Hacktoberfest 2020, one of the feature request was to update the password standard to current NIST standards. This was a standard research I’ve done in the past at my previous company, FormulaFolios as well so I took up the project for Hacktoberfest to implement it, and share why I made those implementation choices.

The current password implementation before these changes requires number, special characters, uppercases, and lowercases for a password. This xkcd post sums up why this is a bad idea which results in less secured passwords.

The NIST documents also recommend checking against known leaked sources for a password strength meter and common passwords to avoid using a password that’s already been found in a data breach.

Dropping the password_histories table

Remove extraneous password validations

Having a password_histories table allows attackers to have multiple passwords to crack rather than just 1 since it’d increase their probabilities of getting at least 1 password to get in.

Extraneous password validations forces a user to need to write that password down on paper and pencil, making it harder for users to remember. What good passwords need to do is be easy on the user to remember and hard for a machine to crack (increased length, but do not enforce complexity to reduce the time to brute force).

From NIST itself:

Clearly communicate information on how to create and change memorized secrets.

Clearly communicate memorized secret requirements, as specified in Section 5.1.1.

Allow at least 64 characters in length to support the use of passphrases. Encourage users to make memorized secrets as lengthy as they want, using any characters they like (including spaces), thus aiding memorization.

Do not impose other composition rules (e.g. mixtures of different character types) on memorized secrets.

Do not require that memorized secrets be changed arbitrarily (e.g., periodically) unless there is a user request or evidence of authenticator compromise. (See Section 5.1.1 for additional information).

In regards to password_histories, a talk by Lance Spitzner or a blog that he wrote on SANS in regards to the matter.

Validation to prevent an existing breached password to be used

Pop up notification if logged in with a password that is found in a data breach

This utilizes HaveIBeenPwned API via Devise Pwned Password gem and fulfils NIST standards of

The NIST document contains other recommendations for improving the password system, such as checking against known leaked sources

I’ve helped code review an implement for 2 factor authentication if a user failed their login 3 times in a row. This helps preventing brute force login attempts.