Microsoft is finally catching on to a maxim that security experts have almost universally accepted for years: periodic password changes are likely to do more harm than good.
In a largely overlooked post published late last month, Microsoft said it was removing periodic password changes from the security baseline settings it recommends for customers and auditors. After decades of Microsoft recommending passwords be changed regularly, Microsoft employee Aaron Margosis said the requirement is an “ancient and obsolete mitigation of very low value.”
The change of heart is largely the result of research that shows passwords are most prone to cracking when theyre easy for end users to remember, such as when they use a name or phrase from a favorite movie or book. Over the past decade, hackers have mined real-world password breaches to assemble dictionaries of millions of words. Combined with super-fast graphics cards, the hackers can make huge numbers of guesses in off-line attacks, which occur when they steal the cryptographically scrambled hashes that represent the plaintext user passwords. Even when users attempt to obfuscate their easy-to-remember passwords—say by adding letters or symbols to the words, or by substituting 0s for the os or 1s for ls—hackers can use programming rules that modify the dictionary entries. As a result, those measures provide little protection against modern cracking techniques.
Researchers have increasingly come to the consensus that the best passwords are at least 11 characters long, randomly generated, and made up of upper- and lower-case letters, symbols (such as a %, *, or >), and numbers. Those traits make them especially hard for most people to remember. The same researchers have warned that mandating password changes every 30, 60, or 90 days—or any other period—can be harmful for a host of reasons. Chief among them, the requirements encourage end users to choose weaker passwords than they otherwise would. A password that had been “P@$$w0rd1” becomes “P@$$w0rd2” and so on. At the same time, the mandatory changes provide little security benefit, since passwords should be changed immediately in the event of a real breach rather than after a set amount of time prescribed by a policy.
Despite the growing consensus among researchers, Microsoft and most other large organizations have been unwilling to speak out against periodic password changes. One of the notable exceptions was in 2016, when Lorrie Cranor, then the Federal Trade Commissions chief technologist, called out the advice given by her own employer. Now, almost three years later, Cranor has company.
In last months blog post, Microsoft's Margosis wrote:
Theres no question that the state of password security is problematic and has been for a long time. When humans pick their own passwords, too often they are easy to guess or predict. When humans are assigned or forced to create passwords that are hard to remember, too often theyll write them down where others can see them. When humans are forced to change their passwords, too often theyll make a small and predictable alteration to their existing passwords and/or forget their new passwords. When passwords or their corresponding hashes are stolen, it can be difficult at best to detect or restrict their unauthorized use.
Recent scientific research calls into question the value of many long-standing password-security practices, such as password expiration policies, and points instead to better alternatives such as enforcing banned-password lists (a great example being Azure AD password protection) and multi-factor authentication. While we recommend these alternatives, they cannot be expressed or enforced with our recommended security configuration baselines, which are built on Windows built-in Group Policy settings and cannot include customer-specific values.
He added:
Periodic password expiration is a defense only against the probability that a password (or hash) will be stolen during its validity interval and will be used by an unauthorized entity. If a password is never stolen, theres no need to expire it. And if you have evideRead More – Source
[contf] [contfnew]
Ars Technica
[contfnewc] [contfnewc]
