Microsoft is removing the policy that passwords should expire after a particular period that was previously part of its security guidelines for Windows 10 and Windows Server. Rather than depend on users tweaking passwords, companies should have a broader approach to authentication and security, it says. And it’s not saying that Microsoft is not changing requirements for minimum password length, history, or complexity. Taking password expiry out of its baseline means that companies can make their own decisions without being penalized by auditors, according to Microsoft.
It has long argued that passwords are inconvenient, insecure and expensive to businesses. It argues that they should be replaced with multi-form authentication and biometrics. It suggested that by forcing regular password changes harms rather than improves security. Users are likely to choose new passwords that are only minor variations of the old, and in any case a password that is stolen is generally used by hackers immediately, so resetting it up to 90 days later is rather a waste of time. Despite calling time on password expiration policies, it’s still common across many, if not most, organizations for passwords to expire after a relatively short period of time.
This removal of password expiration policy will be included in the May 2019 Update. The removal of the password-expiration policies without the addition of other password-oriented security configurations does not directly translate into a decrease in security but, instead, it simply stands as proof that security-conscious organizations need to implement extra measures to enforce their users’ security.
Here are the list of other changes with Windows 10 Version 1903
- Enabling the new “Enable svchost.exe mitigation options” policy, which enforces stricter security on Windows services hosted in svchost.exe, including that all binaries loaded by svchost.exe must be signed by Microsoft, and that dynamically-generated code is disallowed. Please pay special attention to this one as it might cause compatibility problems with third-party code that tries to use the svchost.exe hosting process, including third-party smart-card plugins.
- Configuring the new App Privacy setting, “Let Windows apps activate with voice while the system is locked,” so that users cannot interact with applications using speech while the system is locked.
- Disabling multicast name resolution (LLMNR) to mitigate server spoofing threats.
- Restricting the NetBT NodeType to P-node, disallowing the use of broadcast to register or resolve names, also to mitigate server spoofing threats. We have added a setting to the custom “MS Security Guide” ADMX to enable managing this configuration setting through Group Policy.
- Correcting an oversight in the Domain Controller baseline by adding recommended auditing settings for Kerberos authentication service.
- Dropping the password-expiration policies that require periodic password changes.
- Dropping the specific BitLocker drive encryption method and cipher strength settings. The baseline has been requiring the strongest available BitLocker encryption. We are removing that item for a few reasons. The default is 128-bit encryption, and our crypto experts tell us that there is no known danger of its being broken in the foreseeable future. On some hardware there can be noticeable performance degradation going from 128- to 256-bit. And finally, many devices such as those in the Microsoft Surface line turn on BitLocker by default and use the default algorithms. Converting those to use 256-bit requires first decrypting the volumes and then re-encrypting, which creates temporary security exposure as well as user impact.
- Dropping the File Explorer “Turn off Data Execution Prevention for Explorer” and “Turn off heap termination on corruption” settings, as it turns out they merely enforce default behavior
