How to make weak passwords stronger?

Question

I am storing our customers' passwords with PBKDF2 and I would like to make these weak passwords more stronger (I don't want to restrict user to some very specific password length or special chars etc).

My idea is as follows:

1. Take user (weak) password
2. Generate random string ("salt") of defined size (cca 20 chars), encrypt it (we use Amazon KMS) and save with other user data
3. Combine weak password with this random string (note1) - the final length will be size of random generated salt
4. Generate hash with PBKDF2 from this "stronger" password string

Should this process make passwords more secure / stronger?

note1) How to generate this stronger - "password" it should be some sort of combining original password and random generated string. Some ideas? This algorithm must be deterministic.

Answer 1

The only way to make passwords stronger is to disallow weak passwords. The reason a password is weak is that an attacker can guess it, not because of how you store it.

I've found http://www.passwordresearch.com to be a great resource for academic studies on passwords. You may be interested in Designing Password Policies for Strength and Usability, which explores the effectiveness of policies on making passwords hard to guess, and how easy they are to remember.

Answer 2

If I sign up for your service and use the password "password", all your process is doing is performing a lot of work to hash, salt, rehash, resalt, and assault the same password. Then you store it in your database.

All that data that you want to "add" has to be stored somewhere, and if it is stored, it can be retrieved.

I see no benefit to your proposal over performing the standard hashing and salting processes.

Because in the end, my password is still "password" ...

Answer 3

Should this process make passwords more secure / stronger?

No

The only way to make passwords stronger is to increase there length. complexity helps a little bit, but a passwords entropy increases significantly more when you make the password longer than when you 'require' more of the characters to be users. for example: the increase of 5 more characters to the Alphabet increases the comlpexity of the password with Alphabet+5^n characters. while increasing the number of characters increases the complexity with Alphabet^n+5 characters. the last one is exponetialy more than the first one.

Answer 4

The fundamental problem is that the customer only needs to know their password, and their password can be weak.

What you propose is in effect not changing the fact you use PBKDF2 for storing the passwords, or the customer's base password.

I think your issue might be about threat modelling: which risks are you now protecting against (password database being exposed), and which additional risks are you now trying to guard against?

I don't think there is a major disagreement about user passwords being problematic in the real world, and in the real world, there are some fairly broadly adopted systems, which tend to fall under the general concept of 2FA.

Under this fall things like hardware tokens, TOTP/HOTP code generators (i.e. Google Authenticator), SMS codes (which are TOTP, AFAIK), and x509 (i.e. SSL certificates).

I think the solution in your case is either to impose (stronger) password requirements, or look into a second password, using client certificates, or using some other means of implementing 2FA in some form.

Or both.

Answer 5

The process you described doesn't make the password "stronger", you're just making the hashing process more complex in a way that doesn't difficult an attacker that much. You should assume that an attacker that had access to the password hashes also had access to every other data in your database, including both salts (KMS and PBKDF), in this scenario your hashing scheme doesn't provide any additional security

Password policies are the only way to ensure a minimum password strength. Given that the most important factor for password strength is the length of the password, you could require a minimum length and just recommend to use numbers and/or special characters if you don't want to restrict that much your users

On top of that you may want to provide somekind of two factor authentication like Google Authenticator or a physical token. This won't make passwords stronger but will provide an additional layer of security

Answer 6

Unless your additional random string is stored in an HSM, it will provide little additional benefit.

Instead, the best defense against easily cracked passwords is a combination of three things:

1. Hashing passwords with a very slow hash such as bcrypt or scrypt, with high-cost work factors (a high number of rounds, etc.). This slows down high-speed offline attacks (dictionaries, masks, rules, brute force, etc.)

2. Disallowing well-known passwords with a blacklist. This further reduces the usefulness of straight dictionary attacks.

3. Supporting users in choosing long passwords by A) requiring a certain minimum length; B) encouraging the use of randomly generated passphrases (for passwords that must be remembered) or randomly generated strings (for passwords that can be stored in a password manager); and C) supplying a user interface that supports long passwords (by allowing pasting of passwords into the password field, etc.)

Traditional methods of improving password strength like composition rules are deprecated. Requiring longer passwords is more effective than complexity/composition requirements, as noted in the draft of NIST 800-63b. Must cracking platforms use rules that mimic the psychology of how people create memorable passwords that satisfy such requirements, which reduces the usefulness of composition rules.

Instead, encourage randomly generated passphrases. They can be memorable, yet still resistant to brute-force attacks. Introducing this alternative clearly to users (such as in this Stanford policy) can empower them to choose good passwords.

We cannot fully dictate password selection, but we can control the server-side implementation. Slow hashes and blacklists are essential for this.