>From the article:
*>>For instance, we recommend using system monitoring tools that present users with information about the last login attempt, so they can see if they’re responsible for failed login attempts. <<* Do they really believe that if users are inconvenienced by password changes every 30 or 60 or 90 days, that they'll actually bother to match up their activities with information that indicates last login of the system? The fact that they could not point to an improved security posture by their new stance indicates its weakness. Let's see if they feel the same way about it in 5 or 6 months. The fact is, we are at a good point in computing history to go with changing passwords, since so many online services are doing it. Back when people only had an eternal bankcard pin and a changing corporate password, it would be easy to see how the changing password would be a huge annoyance. Today? Let's see how many users feel that identity theft is a worthwhile trade-off for password changing convenience, after they experience the former. If user convenience is the paramount consideration for information security, then it's hard to see what other authentication and authorization options will be deemed acceptable. -- Two-factor? Inconvenient. -- Digital certificates? Inconvenient. Reducing the scope of exposure is the primary purpose of changing passwords. *>>The new password may have been used elsewhere, and attackers can exploit this too.<< * A. Pure Speculation. B. There's nothing to prevent the current password from being used somewhere else, too. Frankly, if the next password a user selects is used somewhere else, then there is an equal chance that they will use their current password on the next service that they sign up for. They are just employing poor password hygiene and they are not only going to do so if the corporate password changes. *>>The new password is also more likely to be written down, which represents another vulnerability. <<* For any user that is likely to write down their next password, they are also likely to be reusing passwords across sites. See previous point. This means that their poor password practices are *already* endangering the current environment. *>>New passwords are also more likely to be forgotten, and this carries the productivity costs of users being locked out of their accounts, and service desks having to reset passwords.<<* Whine, whine, whine. The deployment of a self-service password portal eliminates this risk, and is not an uncommon solution. What has been offered here is not a reason or a set of reasons, but a set of ill-considered excuses. Anyhoo, it will be interesting what their guidance is next year... Regards, *ASB* *http://XeeMe.com/AndrewBaker <http://xeeme.com/AndrewBaker>* *Providing Expert Technology Consulting Services for the SMB market…* * GPG: *1AF3 EEC3 7C3C E88E B0EF 4319 8F28 A483 A182 EF3A On Mon, Apr 25, 2016 at 6:56 PM, Dave Lum <l...@ochin.org> wrote: > Anyone see the debate on the Patch management list, driven by this: > https://www.cesg.gov.uk/articles/problems-forcing-regular-password-expiry > > > > I don’t even know how it’s a debate other than the desired frequency (no > one-size-fits-all on that IMO). Even six months is far better than never. > With expiring passwords you at bare minimum mitigate employee’s that leave. > > > > *David Lum* > > *Systems Administrator III* > *P:** 503.943.2500 <503.943.2500>* > *E:** l...@ochin.org <l...@ochin.org>* > *A:** 1881 SW Naito Parkway, Portland, OR 97201* > > > [image: Facebook Link] <https://www.facebook.com/OCHINinc>[image: Twitter > Link] <https://twitter.com/ochininc>[image: Linkedin Link] > <http://www.linkedin.com/company/ochin> www.ochin.org > [image: OCHIN email] > > > > > > > > > > > Attention: Information contained in this message and or attachments is > intended only for the recipient(s) named above and may contain confidential > and or privileged material that is protected under State or Federal law. If > you are not the intended recipient, any disclosure, copying, distribution > or action taken on it is prohibited. If you believe you have received this > email in error, please contact the sender with a copy to > complia...@ochin.org, delete this email and destroy all copies. >
