{"id":21801,"date":"2023-10-13T18:06:52","date_gmt":"2023-10-13T14:06:52","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/?p=21801"},"modified":"2023-10-13T18:06:52","modified_gmt":"2023-10-13T14:06:52","slug":"bad-password-policies","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/bad-password-policies\/21801\/","title":{"rendered":"A how-not-to guide to password policies"},"content":{"rendered":"<p>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.<\/p>\n<p>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.<\/p>\n<h2>What\u2019s a password policy?<\/h2>\n<p>\nA 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.<\/p>\n<p>Password policy rules can be diverse, covering:\n<\/p>\n<ul>\n<li>Password length: the minimum and maximum number of characters in the password.<\/li>\n<li>Allowed characters: upper\/lowercase letters, numbers, special characters, emojis, and other characters the password must include; or, on the contrary, not include.<\/li>\n<li>Prohibited combinations; for example, sequences of characters that match the company\u2019s or the user\u2019s names.<\/li>\n<li>Specific bans: for example, passwords must not start with a \u201c1\u201d, contain a straight sequence of numerals (\u201c12345678\u201d), or match some easily guessable pattern (date, phone number, license plate number), and so on.<\/li>\n<li>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.<\/li>\n<li>Password expiration interval: the period after which the user must set a new password.<\/li>\n<li>Password reuse ban: a password cannot be changed to one previously used for the same account.<\/li>\n<li>Ban on user-requested password changes to combat account hijacking by stopping an attacker from changing a password.<\/li>\n<li>Password storage method: in particular, a company-wide ban on <a href=\"https:\/\/www.kaspersky.com\/blog\/security-awareness-training-diy-ideas\/47703\/\" target=\"_blank\" rel=\"noopener nofollow\">password-mentioned sticky notes<\/a>. Or a recommendation to use a <a href=\"https:\/\/me-en.kaspersky.com\/password-manager?icid=me-en_kdailyplacehold_acq_ona_smm__onl_b2c_kasperskydaily_wpplaceholder____kpm___\" target=\"_blank\" rel=\"noopener\">password manager<\/a>.<\/li>\n<li>Administrative measures: if some password policy rules cannot be enforced in the software settings, <a href=\"https:\/\/www.reddit.com\/r\/sysadmin\/comments\/118hxpo\/what_sanctionsconsequences_does_your_company\/\" target=\"_blank\" rel=\"noopener nofollow\">administrative measures<\/a> can be applied to compel users to follow them.<\/li>\n<\/ul>\n<p>Of course, this list is neither exhaustive nor mandatory for all situations. There is no single universal approach (and there can\u2019t 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.<\/p>\n<p>Now let\u2019s see what requirements a password policy should and should not impose. We\u2019ll examine some policy rules that are at best misguided \u2014 and at times downright silly.<\/p>\n<h2>Examples of bad password policies<\/h2>\n<p>\nOverly 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\u2019t use that letter in the password. This is because the administrators ruled that the password must not contain the username from the email address!<\/p>\n<div id=\"attachment_49214\" style=\"width: 3010px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" aria-describedby=\"caption-attachment-49214\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/37\/2023\/10\/13164608\/bad-password-policies-1-scaled-1-scaled-scaled.jpg\" alt=\"Bad password policy: banning a single letter\" width=\"3000\" height=\"4399\" class=\"size-full wp-image-49214\"><p id=\"caption-attachment-49214\" class=\"wp-caption-text\">Registering with a one-letter email address results in a ban on this letter in the password<\/p><\/div>\n<p>A fairly common mistake is to limit the maximum password length. For example, at a tech conference, they did this:<\/p>\n<div id=\"attachment_49215\" style=\"width: 3010px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" aria-describedby=\"caption-attachment-49215\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/37\/2023\/10\/13164643\/bad-password-policies-2-scaled-1-scaled-scaled.jpg\" alt=\"Bad password policy: password too long \" width=\"3000\" height=\"694\" class=\"size-full wp-image-49215\"><p id=\"caption-attachment-49215\" class=\"wp-caption-text\">One of the worst mistakes is to impose a maximum password length. Don\u2019t do it!<\/p><\/div>\n<p>This is probably the most harmful \u2013 also pointless \u2013 rule you can set in a password policy: password length is a <a href=\"https:\/\/www.kaspersky.com\/blog\/strong-password-day\/25519\/\" target=\"_blank\" rel=\"noopener nofollow\">cornerstone of security<\/a>.<\/p>\n<p>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\u2019s an example from another major software developer:<\/p>\n<div id=\"attachment_49216\" style=\"width: 3010px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" aria-describedby=\"caption-attachment-49216\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/37\/2023\/10\/13164704\/bad-password-policies-3-scaled-1-scaled-scaled.jpg\" alt=\"Bad password policy: too many restrictions \" width=\"3000\" height=\"1504\" class=\"size-full wp-image-49216\"><p id=\"caption-attachment-49216\" class=\"wp-caption-text\">Perhaps the most absurd password policy there is: a bunch of weird restrictions, many of which actually harm security. <a href=\"https:\/\/twitter.com\/tedworthy_\/status\/751365313149726720\" target=\"_blank\" rel=\"noopener nofollow\">Source<\/a><\/p><\/div>\n<p>To make users\u2019 life even more confusing, you can provide password rules as a vague paragraph-long description in tiny print. And don\u2019t forget to set a maximum password length of six (yes, 6) characters: cybercriminals will be lining up to thank you.<\/p>\n<p>That\u2019s exactly what one North America\u2019s biggest banks did:<\/p>\n<div id=\"attachment_49217\" style=\"width: 3010px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" aria-describedby=\"caption-attachment-49217\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/37\/2023\/10\/13164732\/bad-password-policies-4-scaled-1-scaled-scaled.jpg\" alt=\"Bad password policy: poorly worded rules \" width=\"3000\" height=\"335\" class=\"size-full wp-image-49217\"><p id=\"caption-attachment-49217\" class=\"wp-caption-text\">Bizarre restrictions with an unclear description are a great way to get up the user\u2019s nose. <a href=\"https:\/\/twitter.com\/GlenReesor\/status\/744187430924881920\" target=\"_blank\" rel=\"noopener nofollow\">Source<\/a><\/p><\/div>\n<p>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\u2019s more fun to let the user guess! Best practice from a major international grocery chain:<\/p>\n<div id=\"attachment_49218\" style=\"width: 3010px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" aria-describedby=\"caption-attachment-49218\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/37\/2023\/10\/13164804\/bad-password-policies-5-scaled-1-scaled-scaled.jpg\" alt=\"Bad password policy: no feedback for the user \" width=\"3000\" height=\"1775\" class=\"size-full wp-image-49218\"><p id=\"caption-attachment-49218\" class=\"wp-caption-text\">The user has to guess what rule(s) they violated! <a href=\"https:\/\/www.davidpashley.com\/2014\/04\/16\/bad-password-policies\/\" target=\"_blank\" rel=\"noopener nofollow\">Source<\/a><\/p><\/div>\n<h2>The right way to handle passwords<\/h2>\n<p>\nLet\u2019s finish with a few tips on how to handle user passwords to ensure an acceptable level of security without too much inconvenience.<\/p>\n<ul>\n<li>Never limit the <em>maximum<\/em> 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.<\/li>\n<li>Always set a <em>minimum<\/em> 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.<\/li>\n<li>Never prohibit the use of any character subsets. If they want to use some exotic squiggles, let them.<\/li>\n<li>Don\u2019t impose too many conditions. Instead, encourage longer combinations of characters \u2014 this is by far the most effective way to make a password really secure.<\/li>\n<li>Provide feedback on passwords during account registration. Users need to understand why their symbol combination fails to meet your password policy.<\/li>\n<li>Don\u2019t send passwords in plaintext over an unsecured communication channel (that means email) if you generate them for users on your end. In general, it\u2019s better to let users generate their own passwords.<\/li>\n<li>And never, ever store their passwords on your side. Rather you should use hashes, preferably salted ones \u2014 check out our <a href=\"https:\/\/www.kaspersky.com\/blog\/how-to-store-passwords\/49101\/\" target=\"_blank\" rel=\"noopener nofollow\">extensive post<\/a> on this very topic.<\/li>\n<\/ul>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"mdr\"><input type=\"hidden\" class=\"placeholder_for_banner\" data-cat_id=\"mdr\" value=\"18690\">\n","protected":false},"excerpt":{"rendered":"<p>Examples of password policies that will have users tearing their hair out \u2014 and why you shouldn&#8217;t employ them.<\/p>\n","protected":false},"author":2726,"featured_media":21803,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1318,1917],"tags":[1474,187,2696,97,1141],"class_list":{"0":"post-21801","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-smb","9":"tag-accounts","10":"tag-passwords","11":"tag-policies","12":"tag-security-2","13":"tag-users"},"hreflang":[{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/bad-password-policies\/21801\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/bad-password-policies\/26368\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/bad-password-policies\/29044\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/bad-password-policies\/26651\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/bad-password-policies\/36347\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/bad-password-policies\/49212\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/bad-password-policies\/26938\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/bad-password-policies\/32655\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/bad-password-policies\/32309\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/me-en.kaspersky.com\/blog\/tag\/passwords\/","name":"passwords"},"_links":{"self":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/21801","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/2726"}],"replies":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=21801"}],"version-history":[{"count":2,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/21801\/revisions"}],"predecessor-version":[{"id":21805,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/21801\/revisions\/21805"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/21803"}],"wp:attachment":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=21801"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=21801"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=21801"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}