Password Expiration/Change Policy 2021

  • We currently have a password change policy where the user is prompted to change their password every 120 days. Issue: We have outside users that can access our system, to view the status of their existing orders (inquiry only). Is it necessary to include these inquiry only users in our password expiration/change list. These users have no access to the business system and cannot make any changes.
    (These users consist of sales representatives contracted by my company to conduct sales business on our behalf)
    I believe adding these types of users to the password expiration/change list will only cause more password resets for forgotten passwords and add no value to maintaining or improving systems security.
    Any comments?

  • My personal belief is that a password policy should be exactly that, a policy.
    IMHO, the policy should be relevant for any and all users that access any of your systems.
    In terms of SOX, I’m not sure what regulations there are about system access, but someone will chime in.
    We hired an external firm last year to audit our IT policies and processes and this was an issue that came up. All of our users had to change passwords every 180 days, but sysadmin, superuser, and DB passwords were only changed once a year.
    The external auditors found this as a problem because our policy clearly states that all passwords must be changed every 180 days.
    Personally, I think forcing contractors to change their password every 120 days is a good thing and your organization should continue to do so.
    edit: There is an excellent multiple page discussion in another thread about passwords.

  • If these outside users actually logon to your network (through VPN for example) for the read access then they need to follow the policy. A web based interface having only read access with password expiry > 120 days shouldn’t bother an external auditor.
    Policy should be granular to accommodate users with different needs and different environments and should have the space for exceptions within the boundaries of acceptable risk. A balance between operational efficiency and acceptable risk should be maintained in the policy.

  • It is possible to have a general policy that applies to all systems, and then have a system-specific policy for any variances from the general policy. As long as the approach and the policies are approved, you’d be covered from a policy standpoint.
    Obviously you want to be careful about how many ‘exception’ policies you create–each exception means more work to document, track, justify during the audit, etc. And if you have too many exception policies, you defeat the purpose of having a policy in the first place.
    Of course, you would still have the question of risk for that external sales force. Your auditors might not be comfortable with the risk of keeping those logins static. What is the worst that could happen? One of them could quit, and continue to use their login to gain specific intelligence and pricing for a competitor if their account was not suspended. Or someone could hack their account and gain that info. etc.

  • Thanks for all your input; you have given me a lot to consider. I was trying to cut down on the administrative password resets. But policy is policy.

  • Hi - I also agree with the good comments offered 🙂 Some additional ideas include:

    1. As you’re enhancing your 3rd party controls, it would be beneficial to look beyond just passwords. If the ‘System Owner’ (business folks) are nearby it’s helpful to briefly interview them on their desires for controls, etc. Some ideas for improved security might include:
    • Ensuring accounts are not shared (at least where it’s feasible to implement)
    • Improving Initial access procedures
    • Improving Termination procedures
    1. You might want to place all 3rd party users into a special security group for Windows 2003 or any other server OS you might be using (to improve global management of these accounts)
    2. Test the 3rd party access routinely, by having your own special test accounts so you can see it as if you there to make certain they are getting no more or no less access than needed.

  • Our company has domain accounts that only have access to their corporate e-mail account and no network resources. In order to comply with SOX 404, do we have to enforce those ‘e-mail only’ domain accounts to change their passwords? Thanks.

  • Hi Anna and welcome to the forums 🙂
    This is an excellent question and I’ll share some thoughts that our members can add to or subtract from. With respect to SOX requirements, it’s also a good question to ask Audit for their opinion of.
    SOX Viewpoint – SOX 404 requires each company to ensure that automated IT financial systems are being properly controlled. Thus, if an employee has no access to network directories where financial results reside, the need for password rotational controls might be seen as ‘NO’. Certainly, adding this control will entail more end user involvement and help desk calls.
    Non-SOX Viewpoint – However when I put on my IT security hat, I’m in favor of changing passwords on email systems periodically for the following reasons:

    • Too much confidential information is sent via email (in unencrypted modes also). When you look at some of the spreadsheets, exhibits, and other documents transmitted – it’s one of the most critical systems, IT should be protecting – whether there’s SOX requirements or not.
    • If a password is shared to another employee, supervisor, etc., password rotations eventually allow the email account to be protected again once the known password expires
    • If an employee in a remote location leaves the company and the termination is not communicated to IT security, eventually the account will be unusable
    • Non-expiring passwords should be used on a very limited and controlled basis everywhere throughout the organization.

  • To add one more comment to Harry’s great response - I don’t like having different controls over SOX and non-SOX activities when the activities are essentially the same. This gets too difficult to manage effectively and will likely lead to a misstep on the SOX side of things.

  • One more brief thought on passwords is that strong password controls should be implemented and mandatory for the Windows server environment . I like the setting of 8 or more characters , letter(s) number(s), and case mix (at least one upper and one lower case character).
    Special characters are even better, but they are more difficult to remember and would probably incur more help desk password resets (although you can use the ‘USD’ to represent the letter ‘S’ and ‘at’ for the letter ‘A’ to help you remember).
    Some links and additional information can be found in this related resource I found yesterday. The 1st link in this blog is good for user security awareness as they can key in passwords and test them directly for strength.
    copy to browser - no www required

  • To add one more comment to Harry’s great response - I don’t like having different controls over SOX and non-SOX activities when the activities are essentially the same. This gets too difficult to manage effectively and will likely lead to a misstep on the SOX side of things.
    Absolutely spot on.
    Ultimately organisations need to get to a place where control processes are embedded so that the burden of SOX compliance becomes far easier. With this in mind it is far easier to have one standard for internal control, and if you have differing requirements to use the highest standard.

  • I agree whole-heartedly with harrywaldron’s ideas on strong password controls, but surely scheduled expiry of passwords is counter-productive to system-security.
    A password that only has a life of a few months won’t be treated with respect. It <b>will</b> be given to others with hardly a qualm, whereas a password that can be kept for a long time will be more closely guarded.
    What is actually happening is that users can’t remember yet another password and are writing them down on post-it notes and sticking them to their monitors - highly secure…
    Surely it would be better for sys-admins to deploy password-crackers and force a change when there’s a hit.

  • Hi and welcome to the forums 🙂
    A few quick comments:
    – Yes, I favor 90 day password rotations (as we use 30 days in some cases and keeping up with them can be difficult - I use an approach of documenting these in a special file, but in a cryptic format … for example I might document ‘rainbow5’ as ‘Noah5’ in a text file that I keep well hidden to personally keep track of dozens of passwords. While folks aren’t allowed to write these down in our company, I’m sure some keep track of these on pieces of paper hidden in their files or desk.
    – For ADMIN and system services passwords, one year manual rotations on non-expiring passwords might work well (or when an ADMIN leaves, there might be a need to change)
    – Better yet, last year we moved to RSA’s SecureID system. It uses 2 factor authentication , e.g., something you have plus something you know. You can’t login without physically having the token which issues a one-time password every minute. Even then the token by itself won’t work as you have to also supply your own personalized PIN.
    – Password phrases are a very long password strings in a sentence type format might be good where they are supported, (e.g., no-is-the-time-for-all-good-people-to-come-to-the-aid-of-their-country ) but they are difficult to implement as most folks want to take the easiest path they can to get authenticated (and I don’t blame them).
    – Complex passwords should be implemented where possible (one letter, one number, case, special characters), as they create more combinations and permutations that are diffcult for cracking programs to decipher.
    – There are several good password testing tools. They can help spot problems, as security is only as strong as the weakest link.
    – Companies need a strong security awareness program and Intranet site with web pages to guide users . Over time, it can make a difference in educating users on security and ensuring they are aware of best practices. Not everyone will follow directions or cares about security, but if it’s done positively and many professionals will improve their practices so that security is gradually strengthened over time.

  • Thanks for your welcome and your reply.
    It’s purely the ‘rotation’, as you call it, I have a problem with. I call it something else.
    I suppose I don’t understand why anybody would recommend forcing someone to change an uncompromised password <b>ever</b>, especially a complex one.
    Yes, if someone who knows the password leaves the company.
    Yes, if it gets discovered by someone, or IT reasonabbly suspects is has been discovered.
    Yes, if a password cracker uncovers it.
    For <b> any</b> other reason it just makes what it’s supposed to be protecting <b>less</b> secore, not more.
    That’s certainly the case in our company.
    We, too, have this impostion. It seems to me ridiculous.
    Whenever I choose a new password, just so I can remeber it myself, it’s necessarily an easier-to-remember one that wins the day.
    In case it’s not clear, I favour <b>never</b> ‘rotating’ passwords, but changing them whenever, and as soon as, necessary to maintain their integrity.

  • The biggest risk of not rotating them is that you may not know that it has been compromised until it is too late. Regular rotation automatically eliminates all compromised passwords until they are shared again.
    I agree that 30 days is too often. 90 days is what my employer uses and that seems reasonable to me. My biggest challenge is coming up with new passwords as I cannot re-use old passwords or similar passwords.

  • I agree kymike and can also empathize on the difficulties of password management … No one likes to change or keep up with passwords (and I literally have dozens of them). As I have a lot of experience with IT audits, if you get 90 day rotations as a standard, I’d count my blessings. No auditor I’ve worked with in my 35 years of IT experience would approve of non-expiring passwords on any system (unless it’s a completely low or non-existant risk involved)
    The best approach I’ve personally found is to keep them secret but record them somewhere as soon as you change them and keep them hidden. Many of the links in the thread below share these dangers.
    http-and-#58;// passwords

  • So what do you choose for the new password?
    One that’s as easy as possible to remember probably.
    One that’s therefore easier to guess or crack.
    Do you perhaps even write it down somewhere?
    Do you ever forget it and have to get it reset by IT?
    And probbably you reuse an old one as soon as that’s permitted.
    And if it had been discovered by some nefarious person then, they now have access again.
    By the way, by ‘you’, I mean just about everybody out there.
    I don’t expect I’m going to convine anyone except myself and my colleagues. Even our IT guys, admit ‘yeah, you’re probably right but that’s how it is’.
    I’m sure password ‘rotation’ as a security idea seemed plausible when someone first thought of it. Having adopted it and touted its necessity no-one is willing admit they might haeve been wrong and really examine its effect. all that gets trotted out is the same old mantra that’s it’s ‘obviously a good thing’, but I think the point is being missed.
    Doctors used to say smoking was good for you. They have now reconsidered their position. Though I susspect some hanker for the old days.

  • The first hit says this:
    With the current password-cracking tools that exist, it is essential to set business passwords to expire after 30 to 45 days. If they are not set to expire within this time, an attacker is given too much time to acquire the essential password information (password hash) and break its code.
    Good grief. This is simply fallacious. Two seconds thought can drive double decker buses through the logic.
    A good password won’t be cracked even after years of endeavour.
    A poor password may be cracked in a few days or less, leaving plenty time till the next rotation to do the dirty on us.
    What we need to know is that good passwords have been chosen.
    Friendly people (e.g. our IT departments) should be using the baddies’ tactics, trying to crack our passwords and forcing us to change our passwords to better ones when they succeed.

  • Hi - A ‘non-expiring’ password could represent an entry point for an ex-employee who is upset with the company or someone who wants customer lists, etc. While the person’s logon account is disabled (hopefully the day they leave the company), there are many special account/passwords floating around that they may know about.
    As folks come and go in companies, not rotating passwords is an exposure if someone has an agenda or is upset with their past work experiences (and you may or may not know this in an exit interview). As I thought about this, an analogy came to mind that a church may even have to change it’s locks every ten years or so 😉
    Some additional comments below:
    So what do you choose for the new password?
    One that’s as easy as possible to remember probably.
    One that’s therefore easier to guess or crack.
    Passwords are always a relatively weak defense. In Windows, they are stored as encrypted ‘hashes’ in the SAM. If a hacker obtains the Windows SAM file, any password can be cracked fairly quickly with some of the commercial tools out there (e.g., Rainbow, Lophtcrack, etc).
    However, if the hackers don’t have access to Windows system files and are pounding away with common passwords, they should be defeated if folks use COMPLEX password settings. Complex password restrictions on servers are where you must have at least one letter, one number, at least one of each upper/lower case letters, and special characters.

    Do you perhaps even write it down somewhere?
    Do you ever forget it and have to get it reset by IT?
    Yes, as I maintain at least 2-3 dozen passwords. However, it’s done in a hidden manner in a text file and as I shared earlier with ‘hints’ rather than the password spelled out. As a shared earlier a password like ‘VaTech7’ will be encoded on my text file for passwords as ‘College7’ so that even if someone finds the file they still may not be able to guess.
    Another Tip: If you can increment passwords, e.g., VaTech1 >> VaTech3 >> VaTech5 (and even skip numbers), that works well in falling back on an old password) However, many systems use ‘password simularity checking routines’ that prohibit passwords that are too close to the expiring one. The ability to fall back on prior passwords can be helpful, although the new system or ‘writing it down’ in a hidden text file works well also.
    As passwords are a ‘necessary evil’, I’m fairly certain most companies will discourage permanent non-expiring passwords. Thus, we have to make the best of it and spending a little time keeping track of these important keys can help.

  • You seem to miss the point that the disgruntled employee has ample oportunity <b>before</b> they leave to misbehave, and that <b>not</b> deleting a leaver’s account immediately is inexcusable negligence.
    None of your arguments offer good reasons in favour of rotating passwords. They merely restate the same tired regurgitations. All the issues you raise are better served by other means: proper scrutiny, timeos account management, strong (in themselves) passwords.
    Yes, passwords are a major weakness, so let’s use the best ones we can. This means -and-lt;nb-and-gt;not</b> forcing people with good ones to change them to poor ones. <b>Any</b> window of opportunity for a malicious person is to be deplored. So relying on the (even 30) day rotation is anathema. The disgruntled employee merely changes the password just before they leave and they have the whole rotation period to wreak havoc.
    Rotating passwords mitigate <b>against</b> security, not for it. Let’s blow the ‘rotating passwords are a good thing’ myth out of the water once and for all. Only a shoddy security system should consider employing them. Let’s ensure their use is considered an admission of incompetence.

Log in to reply