Dispelling modern myths about passwords

<p dir="auto">In the previous posts of this series, it has been described why in general most passwords are insecure, why everybody created insecure passwords for more than 15 years despite their best intentions, and how hackers are quickly cracking these passwords. This article will examine some more modern bad password habits, and explain why - despite all evidence - they are still popular among IT departments and enforced on users. <h5>Human-generated passwords are BAD, get over it <p dir="auto">It has been explained in detail but it is always overlooked, be it for laziness or excess of confidence, or just plain ignorance: <em>human-generated passwords are bad because they are predictable. This happens because they are composed of characters that are not <a href="https://en.wikipedia.org/wiki/Independent_and_identically_distributed_random_variables" target="_blank" rel="nofollow noreferrer noopener" title="This link will take you away from hive.blog" class="external_link"><em>independently and identically distributed (IID). <blockquote> <p dir="auto">A collection of random variables is independent and identically distributed if each random variable has the same probability distribution as the others and all are mutually independent. <p dir="auto">But words are the exact opposite, as they have strict spelling rules which establish a correlation between all characters. Even worse, nature is playing against randomness <em>just because users are human beings typing on a keyboard. <p dir="auto"><a href="https://arxiv.org/pdf/1604.02287v1.pdf" target="_blank" rel="nofollow noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">Recent studies have demonstrated that, when writing, users seem to prefer certain words depending on the number of letters they feature from the right-hand side of the keyboard. Even randomly chosen letters are not IID, as it's been proven they tend to be towards the center of the keyboard. In short, humans are very bad at generating randomness, and this - must be acknowledged - was exposed by Bill Burr, as he chose this assumption as the starting point of his work when drafting the infamous NIST recommendations. <h5>Some "modern" recommendations are also wrong <p dir="auto">Once acknowledged that the NIST recommendations are not generating any robust password, some other recent guidelines that are commonly offered shall come under scrutiny: <blockquote> <p dir="auto">"Build random passwords based on initials of a familiar phrase". <p dir="auto">That would mean choosing a phrase to have some kind of mnemonic aid, for instance, "<em>first operate common key externally recognizable" or "<em>lorem ipsum dolor sit amet", then pick each initial to obtain a baseline and apply NIST substitutions (e.g. <code>f0ck3r and <code>L1dS4). <p dir="auto">This method might help to obtain a little more IID collection, but the results still show several shortcomings even by a cursory inspection: <ul> <li>still too short <li>still based on character substitution, which is ineffective <li>still very easy to crack for a computer <p dir="auto">proving that this method is not better than "scramble words with substitutions" in any way. <h5>They force you to change your password every 30 days. They're wrong. <p dir="auto">Another timeless classic IT cliché that every office has to endure is the request to periodically change the password. The timeframe may vary between "really paranoid" to "mildly annoying", but sooner or later a pop-up message will appear on the screen to remind you that <em>your password will expire. <p dir="auto">It is very unclear why a password - a bundle of bits - should rot and turn bad like sour milk, but there is a historical reason that helps understanding its rationale: after acknowledging that password files can and will be stolen, system administrators craving for security turned their attention at what hackers were doing to attack them, and found out that <em>cracking password requires time: if all users changed their password frequently enough, hackers would not be able to break and use them before they turned into digital garbage, and security would be safe again! <p dir="auto">Even the infamous NIST guidelines recommended changing passwords regularly, at least every 90 days. This advice ended up baked into many standards that businesses needed to follow. <p dir="auto">That however was just another mistake, which caused its fair share of problems. <p dir="auto">With time, it's been demonstrated that users who are forced to regularly update passwords will only introduce minimal changes between each iteration: one letter, one number, one special character - whatever meets the minimum requirement set by the IT policy to make the new password accepted by the system. Users are lazy, and this behavior - in hindsight - was entirely predictable. <p dir="auto">This malpractice exposes passwords to inference attacks, making it easier for an attacker to guess the keyword by exploiting similarities between iterations, which results across time in weakening all passwords even if encryption is applied. <p dir="auto">And finally, there is the human factor: forcing users to change passwords also makes them more susceptible to being forgotten. <p dir="auto">The downsides of forcing this change on users - a habit which is still very popular despite having been proven detrimental - vastly exceed any potential benefit, especially considering that a determined and well structure attack will break the vast majority of passwords encryption before they get changed anyway. In other words, <em>a password should only be changed if suspected to be compromised. <p dir="auto">Despite all that, it is still common practice for many Information Technology departments to enforce a "password change" policy with a timed expiration, which ends up creating a sense of false security while at the same time posing a burden on users and inadvertently setting the premises to have them choose even weaker, less secure passwords. <p dir="auto">(to be continued)