Educause Security Discussion mailing list archives
Re: Password expiration Process ?
From: Gary Flynn <flynngn () JMU EDU>
Date: Thu, 6 Apr 2006 17:21:15 -0400
From: Theresa Semmens [mailto:theresa.semmens () NDSU EDU] We are about to enable the Password Expiration process on our student administration self-service portal. Grades, course registration and financial aid are among the functions that the student can access. As soon as we 'flip the switch', all passwords expire, and the fun begins. My question is two-fold. First, are any of you using a password expiration process in a student self-service environment? We have gone for some time without this, so the password problems we have are the normal 'I forgot' situations. Second, were there any repercussions after password expiration had been enabled? Was it accepted as a standard business practice, or viewed as just another obstacle in the path of the student, faculty and staff?
Theresa, Our home grown LDAP based identity management/authentication system is used for self-service as well as a multitude of other applications. People manage their "JMU eID" password through a web application. The system has always provided for password expiration so we didn't face the situation of having to turn it on. There is a "secret question" function tied to it that will reset the password to a default known ( hopefully ) only to the account holder. This decreases the number of helpdesk calls but I don't know the figures. I do know that password related calls are the number one or number two source of helpdesk calls making up about 20% of the total. If the person does not have a secret question set up, they must physically visit the helpdesk and present picture ID to have the password reset to the known pattern. For the past several years, we used a 190 day password expiration time but switched last semester to a 90 day cycle. I believe this was due to state recommendations. We send email notifications as the expiration time approaches. During the password change process, people go through a web based security awareness presentation. Both the password change process and the security awareness material injected into it has drawn its share of ire but some folks have also had a positive reaction. In any case, we have not yet had a mutiny. We are researching alternative and supplemental authentication systems for various populations. ---------------------------------------------------------- <ambivalent musings> I started writing this to defend password expiration policies. By the time I finished, I think I talked myself out of it and into believing we need something much more effective. It wasn't a complete waste of my employer's time as it gave me a chance to think more about two-factor authentication which is a project that I need to start on soon anyway. :) The primary purposes of periodic password changes are: 1) To reduce the time available to an attacker for a password guessing attack 2) To regain control of an account when a password has already been compromised 3) To limit damage when a password has been compromised 4) To deactivate an unused account. There are much better ways of doing this directly than by using password expiration so this purpose won't be mentioned again. Lets look at each of the first three in turn. ******************************************************************** 1) To reduce the time available to an attacker for a password guessing attack. ********************************************************************* How do they guess? a) Continually access the system trying different passwords. This should be adequately mitigated by inserting delays between unsuccessful login attempts. Additional mitigation can be provided by log monitoring and, at the risk of a denial of service, account lockouts. b) Gain access to a password hash or encrypted password. 1) Directly sniff the wire. Client configuration can partially mitigate this as can network design and application choices. 2) Man in the middle. Client configuration and user practices can partially mitigate this. Client and server certificates can partially mitigate this. MAC address assignments to switches and ARP monitoring can partially mitigate this. 3) From a client that freely provides a hash if the ( possibly malicious ) server asks. Client configuration can partially mitigate this. 4) Compromise a client that stores encrypted authenticators locally. There is probably no need to guess here. The clear text authenticators are probably typed where a keylogger can grab them or they can be used directly in a replay attack. 5) Compromise a host system where the hashes or encrypted passwords are stored. This has profound implications that go beyond password expiration. In all cases, risk can be partially mitigated by using strong passwords but they have to be *really* strong these days to be effective. Processor speeds, distributed computing, and precalculated dictionaries and tables make most of the passwords in use today inadequate and crackable in a relatively short amount of time and the situation is only getting worse. Unless *much* more stringent password composition policies are *enforced*, password expiration policies would have to be ridiculously short - on the order of a few days - to be effective at mitigating guessing attacks. The question then becomes how effective such policies are at regaining control of an account or limiting damage once a password is compromised. ********************************************************************* ********************************************************************* ********************************************************************* 2) To regain control of an account when a password has already been compromised ********************************************************************* How effective are password expiration policies at this? How helpful? That depends upon two things. 1) Was the password compromised in a way that will lead to the new password being compromised? If the desktop is compromised with a keylogger, the new password will also be compromised. If the password is synchronized with one used on a compromised host, the new password will be compromised. 2) Was the password compromised and the account or system subsequently backdoored eliminating the need for the new password? In some cases, changing the password will lock out the intruder. The question then becomes, will it be too late? ********************************************************************** ********************************************************************** ********************************************************************* 3) To limit damage when a password has been compromised ********************************************************************* How effective are password expiration policies at this? How helpful? That depends entirely on the motivation and capabilities of the person compromising the account. Do they want to delay use of the account past the password expiration date? Do they want to use it now? Are they ready to use it now or do they need to do some research and setup? Is it a one-time thing or do they want perpetual use? Will they share or sell it to others? The same questions then apply to the new owners. How long are we willing to allow an account to remain compromised? Is there a big database out there of compromised accounts sold and traded like credit card numbers and saved for future purposes? ********************************************************************** ********************************************************************** How effective are password expiration policies at mitigating password guessing attacks. Today, probably not much. How effective are password expiration policies at regaining control of an account or limiting damage? I don't know the answer to that nor do I know of any studies. I've seen stories of systems being compromised and used for long amounts of time but not individual accounts. Anyone have any information? What I do know is that we, to this date, have had no known security incidents that would have been prevented by a password expiration policy beyond a few days. Anyone else care to volunteer similar information? One has to ask whether the resources applied to dealing with password expiration would better be applied to other mitigation methods. On the other hand, one also has to ask whether those resources are insignificant or would be sufficient. Would other, admittedly more effective, methods cause as much or more support headaches and dissent as the password expirations and consume more resources? Will an organization be willing to assume the higher costs of a more effective solution? Setting a password expiration policy may be the most painless solution ( that isn't really much of a solution ) but gets a check box signed off that was designed for the threat environment of twenty years ago. Today's threat environment is much different with ubiquitous network computing, the Internet, accessible services, intertwined business processes, universal, multiuse accounts, and the growing sophistication of today's criminal. Very few laymen can effectively maintain and operate a desktop computer in a secure manner these days and the statistics on infections and BOT networks demonstrate that by the resulting large number of compromised computers...and probably the accounts accessed from those computers. Then you have to add the folks that synchronize their organizational passwords with eBay and AOL and type them into web forms, phishing sites, open labs, and wireless hot spots. Accounts will be compromised. Even if the account holder doesn't care whether their account information is compromised or that someone can drop a course or perform other actions in their name, the organization must protect itself on four fronts: 1) Constituents must be directly protected from compromised accounts that have access to third party information. 2) Constituents and the organization's infrastructure must be protected from the significant increase in risk posed by an attack against a system using a valid account versus an attack against a system by someone without a valid account. 3) Other organizations may be affected by a compromised account. Say, for example, an email, business process, or unix shell account. And if federated identity systems like Shibboleth are to have any value, then there must be some expectation about the integrity of local, organizational accounts. 4) Then there are passwords ( i.e. PINS ) protecting smartcards and hardware tokens. Likely as not, these devices are used to help protect particularly sensitive accounts. But if the password is compromised, because it is stored on a desktop, synchronized with others, or other ways, the token may as well be a credit card. And where does that leave PKI and digital signatures? With many applications accessible world-wide, there is little room for error. The solution lies in: 1) Much, much, much better monitoring and response systems that can detect account use fraud in much the same way as banks detect credit card use fraud. Of course, this will lead to occasional account inaccessibility due to a false positive from something like someone studying abroad, remoting in multiple times through a sequence of computers, or misbehaved applications. 2) Authenticators that are stronger than memorized, multi use passwords. Typically, though not necessarily, 'something you have' whose use is typically authorized by typing a password. Replacing the authorization password with *token stored* biometrics may be the best solution assuming we're willing to accept the risk of a false positive on a stolen 'something you have' as well as the support headaches associated with an occasional biometric false negative. Passwords don't have to be typed into the suspect desktop and the biometric data does not get stored in a central database where privacy and mass biocompromise are issues nor stored on the desktop or transferred over the wire which presents similar issues. I think a OTP type token (i.e. SecureID) is probably more secure than a token that holds PKI information but the latter will probably be much more useful in the future. I think there are some that do both though not with biometric authorization yet. Of course, there is going to be a password associated with the fingerprint enrollment process that will have to be typed into the desktop, remembered, and protected. Can we ever get rid of them? Are we going to have password expiration policies on token PINS and biometric enrollment passwords? :) Should banks have PIN expiration policies on their ATM cards? 3) ( cough, ahem ) Secure desktops Am I ready to say password expiration policies are totally ineffective and should not be used? No. Particularly for high value accounts that may be targeted where any little edge is necessary and where the value is such that support headaches are dwarfed by potential losses. On the other hand, I *am* ready to say that password expiration policies are close to being totally ineffective and should be replaced with other mitigation methods ASAP. We're only fooling ourselves by using them. Whether real protection for the integrity and ownership of our computer accounts will make palatable the extra support requirements, costs, complaints, and procedures associated with those measures only the future can tell. Typical of security, eh? :) </ambivalent musings> -- Gary Flynn Security Engineer James Madison University www.jmu.edu/computing/security
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
Current thread:
- Password expiration Process ? Theresa Semmens (Apr 06)
- <Possible follow-ups>
- Re: Password expiration Process ? Scott Bradner (Apr 06)
- Re: Password expiration Process ? Franklin, Elliott (Apr 06)
- Re: Password expiration Process ? Penn, Blake (Apr 06)
- Re: Password expiration Process ? David Lundy (Apr 06)
- Re: Password expiration Process ? Gary Flynn (Apr 06)
- Re: Password expiration Process ? Drews, Jane E (Apr 07)
- Re: Password expiration Process ? Kenneth G. Arnold (Apr 07)
- Re: Password expiration Process ? Cal Frye (Apr 07)
- Re: Password expiration Process ? Theresa Semmens (Apr 07)
- Re: Password expiration Process ? Theresa Semmens (Apr 07)