It’s Time for Users to Pony Up and Quit Reusing Passwords
Did you ever notice that no two Thoroughbred race horses are ever named alike? Did you ever wonder how they do that? And did you wonder if that uniqueness has anything to do with your responsibilities as a C-level executive?
Training Users to Stop Reusing Passwords
When you have numerous users and services under your protective umbrella, you expect those users to help defend the resources you access daily. However, many of those users are overwhelmed with identification and authentication processes in their personal and professional lives, almost all of which require some sort of password entry. Naturally, they will seek ways to make their lives easier.
Some of those methods can cripple your attempts to secure your sensitive information. You may not be particularly concerned with how your users secure their Facebook accounts, but poor security on another site is nearly guaranteed to reduce the security of your resources.
Here we’ll discuss password complexity and password reuse. I hope to help you convince your users to make their passwords more complicated and attach even more unique passwords to their various IDs, including the ones you gave them.
Of the passwords that were stolen last year, the most common was the number sequence “123456.” This unsophisticated entry has been at the top of the list for several years. We can assume that this easy password is a response from users who feel that the requirement to enter a password is a nuisance. If users believed that protected information or applications were of value to them or to the company, they would likely invest more effort into creating better passwords.
One possible remedy is to require users to create more complicated passwords. We can do this by implementing controls within an identity and access management (IAM) system that enforces rules for an acceptable password. I introduce these policies to my users by explaining some rules of horse naming and why those rules are important to that industry. This often helps users make the mental leap to understand why password controls exist and why the rules are important to the security of our applications and data.
Use Horse Sense
My wife and I currently own five horses and have had more than I can count come through our farm in Lexington, Kentucky. There are very specific rules to naming a Thoroughbred horse that is going to race. These rules exist to aid in the identification of the horse for racing and breeding. The public wants to know that they are putting money down on the correct horse, and breeders want to be sure their mares are bred by the right horses, selected for their bloodline and racing performance.
I believe we can help our users understand why unique passwords are important by referring to a few of these rules. It might, at least, help them to remember the rules of our policy when the system rejects new passwords that don’t meet the criteria.
There are 17 rules to this horse naming convention, not including an additional stipulation that the Registrar of the Jockey Club gets the final say. I’ll only mention a few as they relate to password rules:
- Maximum of 18 characters, including spaces and punctuation: We typically need to enforce a minimum password length, but a maximum may be necessary to address application input limits and other factors.
- No names should consisting entirely of numbers: A Thoroughbred cannot be named “123456,” and that should not be an acceptable password, either. Most password policies require a combination of uppercase and lowercase letters, numbers and special characters.
- Do not duplicate the names of horses over 10 years old that have not raced or bred for five years: I doubt we’ll get to prohibit password reuse for five years, but we should, at least, mandate that a password cannot be reused within 10 password changes and/or changed more than once a week. This slows down users who simply adjust their passwords enough times to return to their favorite one.
- Permanent names: Some horse names have been set aside and can never be reused, such as Secretariat. IT manages should identify dictionary passwords and special words that should not be used as passwords, such as “password.”
To strengthen passwords among our user base, we use a list of millions of passwords that have been stolen recently. Even though there are millions of users and accounts, they all reduce down to a relatively small set of passwords.
People are reusing passwords across many sites and accounts, which makes it much easier for bad guys to break in. All they need is a simple application that tests a user ID against a short list of possible passwords. If none of those work, they move to the next user ID on the list.
Fraudsters don’t even have to perform tough number crunching to come up with thousands of possibilities for each ID. Once they log in successfully with a user ID and simple password, they try the known combination on a number of other valuable sites. The only solution here is to use complicated passwords unique to each account.
We solved the problem of simple passwords by implementing new rules in our IAM system. If someone is reusing passwords and that password is stolen from a breached system, however, all the user’s accounts that share the same login credentials are vulnerable. Not even password complexity can protect accounts when password reuse is rampant.
User Education Is Key
Now that we’ve forced a bunch of rules on our users, let’s help them make up some new, secure and compliant passwords for all the sites they use. Sometimes, users don’t know what makes a good password. That’s where we can help them think of something clever and secure.
When a breeder or new owner of a Thoroughbred selects a name, they can use any combination of the foal’s lineage or anything else that comes to mind, as long as it fits within the rules above. The rule-makers for other breeds such as Quarter Horses have other standards, such as using words from the dam (mother) and sire (father) to link the foal to its lineage. Hang in there — we’re just about to make the leap from horses to application security, I promise.
Our mare is officially named Stormin’ Scooter, but we just call her Scooter. Her grandfather was Storm Bird, so you can identify a common theme in the new name. Had we bred Scooter to Secretariat, we might have come up with Storming Secretary, and her name would always remind us of her lineage.
Similarly, you can help your users create unique, complicated passwords by combining components of the site or application being protected. When creating a password for a TicketMaster account, for example, a user might fondly remember his or her first concert, where it was and how much the ticket cost. If a user saw the Eagles in Phoenix and paid $110 for the tickets, he or she might use the password “EaglesPhoenix110.”
The key here is to focus on complexity and quit reusing passwords. Of course, multifactor authentication helps tremendously, but that’s a topic for another article.