Despite all the changes that have occurred in the field of information security over recent decades, passwords still remain one of the most important elements of data protection. And when we talk about passwords, password policies become the center of our attention.
In this post, we explain the mistakes to avoid when creating a password policy to provide an acceptable degree of security while not unnecessarily frustrating users with OTT policies that make no sense.
What’s a password policy?
A password policy is a set of rules designed to motivate users to use strong passwords and handle them properly. A password policy can be a recommendation or a requirement. Nowadays the latter is more common: administrators of online services and corporate IT infrastructure set rules for password usage in the settings of the software deployed.
Password policy rules can be diverse, covering:
- Password length: the minimum and maximum number of characters in the password.
- Allowed characters: upper/lowercase letters, numbers, special characters, emojis, and other characters the password must include; or, on the contrary, not include.
- Prohibited combinations; for example, sequences of characters that match the company’s or the user’s names.
- Specific bans: for example, passwords must not start with a “1”, contain a straight sequence of numerals (“12345678”), or match some easily guessable pattern (date, phone number, license plate number), and so on.
- Password denylists: tables of exceptions that satisfy the general policy requirements, but are considered unsafe for another reason; for example, leaked passwords known to have been exposed.
- Password expiration interval: the period after which the user must set a new password.
- Password reuse ban: a password cannot be changed to one previously used for the same account.
- Ban on user-requested password changes to combat account hijacking by stopping an attacker from changing a password.
- Password storage method: in particular, a company-wide ban on password-mentioned sticky notes. Or a recommendation to use a password manager.
- Administrative measures: if some password policy rules cannot be enforced in the software settings, administrative measures can be applied to compel users to follow them.
Of course, this list is neither exhaustive nor mandatory for all situations. There is no single universal approach (and there can’t be one), because a password policy is always a balance between security and user convenience. The right balance needs to be struck in each individual case.
Now let’s see what requirements a password policy should and should not impose. We’ll examine some policy rules that are at best misguided — and at times downright silly.
Examples of bad password policies
Overly specific password policies can lead to unexpected consequences. For example, the website of a well-known software developer lets you register with a single-letter email address (for example, k@companyname.com), but then you can’t use that letter in the password. This is because the administrators ruled that the password must not contain the username from the email address!
Registering with a one-letter email address results in a ban on this letter in the password
A fairly common mistake is to limit the maximum password length. For example, at a tech conference, they did this:
One of the worst mistakes is to impose a maximum password length. Don’t do it!
This is probably the most harmful – also pointless – rule you can set in a password policy: password length is a cornerstone of security.
The mistake can be compounded further by specifying just one permitted password length, and a bunch of other wrong-headed rules that put user accounts in danger. Here’s an example from another major software developer:
Perhaps the most absurd password policy there is: a bunch of weird restrictions, many of which actually harm security. Source
To make users’ life even more confusing, you can provide password rules as a vague paragraph-long description in tiny print. And don’t forget to set a maximum password length of six (yes, 6) characters: cybercriminals will be lining up to thank you.
That’s exactly what one North America’s biggest banks did:
Bizarre restrictions with an unclear description are a great way to get up the user’s nose. Source
In some cases, if a user-created password fails to meet the requirements of the password policy, no explanation is given about which rule was violated. Apparently, it’s more fun to let the user guess! Best practice from a major international grocery chain:
The user has to guess what rule(s) they violated! Source
The right way to handle passwords
Let’s finish with a few tips on how to handle user passwords to ensure an acceptable level of security without too much inconvenience.
- Never limit the maximum password length! And if for some reason you need to do so, at least inform users about it. One of the worst practices is to lead users to believe they can create a password of any length, only for it to be shortened without their knowledge.
- Always set a minimum password length. Better still, get users to create only long passwords, which means eight characters at the very least. Ideally, set the lower limit to something substantial: 12 characters or even 16.
- Never prohibit the use of any character subsets. If they want to use some exotic squiggles, let them.
- Don’t impose too many conditions. Instead, encourage longer combinations of characters — this is by far the most effective way to make a password really secure.
- Provide feedback on passwords during account registration. Users need to understand why their symbol combination fails to meet your password policy.
- Don’t send passwords in plaintext over an unsecured communication channel (that means email) if you generate them for users on your end. In general, it’s better to let users generate their own passwords.
- And never, ever store their passwords on your side. Rather you should use hashes, preferably salted ones — check out our extensive post on this very topic.
from Kaspersky official blog https://bit.ly/3tw817g
via IFTTT
No comments:
Post a Comment