If you allow users to authenticate to your application, it is important to store and manage user identities in a “safe” format within your identity system. T-Mobile Austria came under fire in early 2018 after a customer service representative tweeted that agents can see the first 4 characters of users’ passwords and that they store the whole password to validate users’ identities. Whether they store the parts or the whole password in plaintext, a password should never be known or discoverable by anyone but the user.

That is why encryption should not be used for passwords. Anyone with the key will be able to decrypt the password back into plaintext. When handling or storing passwords in a database, all passwords need to be hashed. Hashing is a one-way method of taking a string and transforming it into a fixed value as a representation of the original string. Some common password-based hashing algorithms to use are argon2, scrypt, bcrypt, and PBKDF2, with appropriate work factors (time, iterations, and parallelism).

Why are some methods better than others for password hashing? They are purposefully slow and require more resources when computing the hash, lowering the efficiency and effectiveness of brute force attacks to crack passwords. A unique “salt”, a random string appended to a hash, should also be used for each hash to prevent the use of rainbow tables, a pre-generated table of all passwords and their associated hash, to quickly crack password hashes.

It may seem unimportant, something you set and forget, but trends are starting to move in the right direction for password complexity requirements. It’s now a standard to require a minimum password length and certain types of characters such as uppercase, lowercase, numbers and a symbol but let’s face it, humans are terrible at creating passwords. “P@ssw0rd” and “Spring2019!” could satisfy most password requirements while being one of the first things checked against in a dictionary attack. This is why it is important to coach users on the right behavior rather than solely relying on password requirements to do so.

Visual indicators of potential password strength can be useful for preventing the worst of passwords.

As examples:

  • Dropbox maintains an open-sourced password strength estimator, zxcvbn. This tool checks against the top 30,000 most commonly used passwords, recognizes simple character/symbol substitution (l33t speak), factors in repeating characters and issues a strength score.
  • Troy Hunt’s haveibeenpwned? API v2 can be used to check passwords against dumps from data breaches to see if compromised passwords are being reused.

One of the strongest mitigants to deal with the challenge of strong authenticators is to simply reduce the value of the password itself. You can accomplish this by giving your users the ability to enable two-factor authentication (2FA) on their accounts. If a user’s password has been compromised but has 2FA enabled, the usefulness of the password by itself is diminished. Each authentication method has its own advantages and disadvantages but the most popular methods are SMS (which should be avoided), Time-Based One-Time Password (TOTP), HMAC-based One-time Password (HOTP), push notifications and the up and coming Universal 2nd Factor (U2F).

Stay Updated with Dwolla