Password cracking is easier than you think. With only a few ingredients, one can flip a switch and start a brute force attack. Sure, trying endless combinations is a function of time, which is the principal deterrent. However, the smartest attackers know a few shortcuts and tricks to getting access to an account quickly.

Determined password crackers look for information to whittle down the number of guesses they must make, effectively reducing the amount of time needed to break in.

Why, then, do we as application developers readily give up valuable clues to hackers? What can you do better to discourage hackers and protect your users’ accounts? What can you do that doesn’t involve overly complicated platform changes?

1. Don’t reveal password criteria to your users on your login page in the form of an error message or hint (e.g., your password must contain a capital letter and three numbers). This seems obvious! A password cracker can easily visit a login page - essentially the front door of your application - and get valuable information with minimal effort. From there they would eliminate certain permutations, and save time, by feeding the parameters you’ve provided to their password guessing programs. In this case, a hacker can eliminate possibilities without ever having an account of their own. Here, not even a paywall slows them down.

2. Don’t reveal password criteria to users when creating an account or resetting their password either. In this case, a hacker goes beyond the login page to look for clues. Never reveal password criteria. Password criteria show hackers the options that would never work and, thus show the way to a subset of password tables to use. Password tables (databases of combinations of characters based on common passwords and often dictionary words) are enormous and varied. The fewer tables hackers have to rely on, the more specific their tables become, and the closer they come to an answer.

3. You may require a capital letter or a number, for instance. You may disallow certain characters and require a minimum length but do those checks on the back-end. Don’t directly report criteria to the user; instead, use a password strength meter. List suggestions, not rules, for making weaker passwords stronger. Be suggestive but never exact. (Remember most users are not novices when it comes to creating passwords. They won’t need much guidance to create a strong password.)

4. Change your password criteria. Nothing’s stopping you. Changing your password requirements on the back-end won’t overwrite or make obsolete old requirements so long as you don’t validate user input before doing the comparison to the encrypted password hash in your database. (Validating password input, i.e., telling users whether or not they’ve met your password requirements as they login, makes user input more vulnerable anyway. You do not want to validate password input when accepting a current password.)

But, how to start over? How to do better? How to change your password criteria?

Some examples: Make two numbers a requirement for a week. Require a ten-character minimum another week. Make two non-alphanumeric symbols a requirement for a day. Mix and match. Rotate. Switch. Create variation in your account passwords. It’s easy. You can automate the rotation of password strength criteria. Just create several sets of criteria and use the time of day or time of year to rotate.

But, is it worth the trouble? Will changing password criteria actually make a difference?

It is. It will. If you have only one kind of password, all of your passwords become more vulnerable. Hackers can apply the same password tables to all of your user accounts. If you have a diverse sampling of password character composition, all matched against different and ever-changing password strength criteria, your passwords are that much safer, password cracking that much more difficult. Hackers are left targeting fewer passwords at a time. They’re left with more wait-time, a more complex process of deduction, and a headache.

And what’s it to you, to your users, limiting password hints and changing password criteria? These suggestions are of the easier-done-than-said variety. Stop giving hints to password crackers. Change password requirements. Force hackers to work, wait, and rely more and more on luck, and less on elementary deductive skills.