Today there was a question pitched by one of the guys at work as to why we bother having such things as a password expiry / enforced change. My answer (in true Rob fashion), rambled a little (ok, a lot) but I’ve consolidated it below and made it generic to suit anyone facing the same line of questioning…
The reason passwords are set to expire, is it limits the exposure of compromised credentials.
If someone was to ‘shoulder surf’ you as you logged in/unlocked you screen saver, they can then impersonate you on the network, performing actions that you are responsible for (or at least linked to via logs/audits).
- If your password never expires, they can continue doing this until such time as you forget your password and a new one is created, or you choose to change your password of your own volition.
By the same token, if a malicious person didn’t have physical access to you (to see you type in your password), they could try to guess what your password is through knowledge of our complexity rules in addition to common user behaviours.
- Common behaviours are to use ‘dictionary based’ words, with or without substitution of common letters for numbers/symbols.
- The bad guys have already thought of this and there are password lists based on dictionary words, dictionary words with common substitutions and common patterns such as 123456, qwerty etc.
- They’d probably also be inserting the names of the significant people/pets/dates in your life into the attack file so may need to friend you on Facebook to grab some of that first.
Culturally, we (people in general) do NOT value the security/secrecy of credentials and the number of dictionary and easily factored passwords currently in use is evidence of this. It’s my view (shared by others) that reliance on password/pass-phrases has had its day and more secure mechanisms are required for users to authenticate themselves to systems.
In the interim, IT departments continue to crank up the complexity requirements (with the trade-off of post-it notes or basic number/letter substitution into dictionary words) and/or decrease the password refresh timing (with similar outcomes).
User Experience is key…The thing most technical folk neglect to account for, is the user-experience and cultural change required for such initiatives to work. For those trying to enact change, there are some good tricks to get a memorable pass-phrase which does NOT include a dictionary word.
One method is to get a phrase with personal meaning to you (so it makes sense, is memorable, is unique(ish)) and then take the first letter of each word in the phrase… for example:
“Seriously, looking forward to Christmas and BBQs”
and throwing a number on the end or in the phrase. That would make the phrase convert to “Slf2Cab1” – 8 characters, mixed case, contains number(s)… WIN.
Umm… just don’t use THIS EXAMPLE as your password, that would just be dumb 🙂
Bottom LineEssentially, an expiry time-frame should be less than that which would be required to brute force the credentials. Obviously factoring a password (aaaaaaa1, aaaaaaa2, etc) takes longer than a dictionary based attack (passwrd1, passwrd2, passwrd3…).
This is why should require a significant amount of complexity so that the passwords must be factored, and cannot be attacked via dictionary.
The upshot of all of this is that processor cycles and bandwidth is cheap, many services requiring a valid username and password have an account lockout policy that you would need to stay underneath while making your guesses – but that constraint aside, the only thing between your credentials and the bad guys getting a win, is the ability to guess or factor your pass-phrase.
We set an expiration to ensure that ensures:
- If your account is compromised (and undetected), it is only exposed until your next forced reset
- If guessing your pass-phrase the bad guys need to win before the next forced reset comes along and makes them begin from scratch, or they trigger the account lockout.
Hope that helps answer some of the questions you may be getting…
Comments
3 responses to “Expiring Passwords”
Hi Rob, (Comment attempt take 2)
This topic is something that I have spent many hours pondering on. I’ve worked in and observed environments where this policy is both enabled and disabled.. I have to say that honestly I feel that a policy of forcing the users to change their password does nothing towards increasing the security of the organisation.
I see this from 2 sides; the users and the organisation.
From the user’s perspective this policy is nothing short of frustrating. Many users do not think in the same way that a security architect does, so they do not see the importance of security related policies; more so when it creates a problem for them.
I’ve seen many many instances where the user has resorted to writing down their current password and attaching it to their desk/monitor. In some organisations this is actually common practice that is passed down from management to employees because everyone has the same grievance with the policy. In other instances people utilise the same password, but increment a digit on the end of it. I’ve never actually met someone who wasn’t an IT network or security specialist who actually creates a new unique and secure password on every iteration that isn’t written down or stored somewhere.
In some organisations this policy actually devalues the users password. The user knows that because they will be forced to change it soon there is very little risk in giving it out to other employees to access systems they otherwise would have to wait for (e.g submit an access request through to the IT department). I
So I can honestly say I have never seen an instance where this policy has been correctly utilised by the user base of the organisation. As much as we (as IT professionals) would like to think it is.
Now, from the organisations point of view I understand as far as “lets check this box to force our users to change their passwords because it’s more secure”; but I think that this is an urban myth more than anything.
Let’s say that there was a security breach on the organisation. It’s highly unlikely that a user’s credentials were acquired and used. But for sake of discussion we’ll say that this is the method they used.
Any attacker is not a completely amateur would immediately ensure future access to the organisation regardless of password changes.
If the attacker’s motive is damage, then they would start immediately and be done in a matter of hours, not days/weeks/months. If they wanted future access again they would install software to ensure this was the case (trojans, keyloggers, remote desktop services, shell services etc).
I think the organisation is better off allowing users to keep a single password, this increases the perceived value of the password to the user, stops them writing it down and stops them using the same password with minor alterations.
I also think that the organisation is better off allocating resources to other policies that be more effective in limiting the damage of a potential hacker. Some policies I would like to see introduced in more organisations (off the top of my head) are:
#1. Time-based login rules. 99% of users do not need access outside of 8am-6pm window. Their accounts should not be allowed to login during this time.
#2. IP/ISP based filtering for remote connections to internal systems. (web mail/vpns etc)
#3. smart-phone tethering for internet access for travelling staff. (this allows you to implement #2)
#4 Intrusion detection systems
I’m keen to hear your thoughts on this topic, as my opinion differs greatly from the argument you have provided in your post.
Regards,
Scott.
As much as we may not like it, passwords are still a necessary evil, they’re something that users ‘understand’ and an audit point for many systems and international standards. Auditors tick boxes and don’t get involved in esoteric religious discussions around the real-world worth of passwords in providing security for accounts where authorisation or authentication is required. IF you don’t have what they need to see for the audit, you fail on that point – fail enough points and you will have a hard time convincing your customers that your business can be trusted.
Two factor authentication is problematic in that token get lost and that then brings the security back to the denominator of a password to request/authenticate a new token and/or a (expensive) helpdesk call at which point the social engineering vectors come into play.
I don’t know that you’d find many IT professionals who live under the illusion that users all comply with the policies in existence, I also believe that we are often our harshest critics, or at least we should strive toward this goal.
Users are of course right, however – while the world of passwords continues to exist, it is incumbent on the security architect, HR trainers, group managers to inform and educate users as to the policies, why they exist and the consequences of breaches (such as writing them down). Again, the behaviours often differ greatly from the stated policy and this is where audits for clear desks, floor walking and actual communication with user groups proves its worth. Unfortunately, as you’ve identified, the all too common reality is that managers do not understand/believe in the policies themselves thus it becomes extremely difficult to enforce policies on employees without first/also enforcing the policies and breach consequences on their managers.
I’m not sure what you’re basing your attack scenario on, but hash files are a prime target for exfiltration from an organisation for offline cracking. Very few truly effective attacks take place in a short amount of time, generally the malicious party will perform a fair amount of reconnaissance work prior to the initial breach attempts, the initial break should be kept as low key as possible, and from there the internal mapping takes place to understand the environment they are invading so the most vulnerable high value targets can be compromised, hopefully (for the attacker) without detection. An attack as you’ve described would tend to be somewhat unsophisticated, noisy (in terms of logging/detection) and generally simple to rectify – if all attackers were as uncouth as this, our jobs would be significantly easier!
Most companies I am aware of are moving toward single sign on (SSO) which I believe to be a “good thing(tm)” – at least in most situations for the greater percentage of users. Federation of authority via SAML assertions (and the like) are also becoming more mainstream which also limits the number of passwords required and/or the systems in which they are recorded, thus reducing the surface area of risk.
Security is all about layers, defence in depth etc. and I agree that resource tends to be spent elsewhere – the time based login is intriguing, I can see it’s worth – however in situations where out of band access is required, the potential for socially engineering the unlock again would raise its head.
Some days I think I’d rather be a Personal Trainer, or maybe a greens keeper… this security gig can get too multifaceted too quickly. 🙂
Hmmm a good read. I agree that we’re stuck with passwords for some time yet, but i don’t think we should put policies in place just to tick audit boxes for the sake of ticking boxes, especially when studies indicate they may decrease the actual security profile for the organisation.
http://newschoolsecurity.com/2012/01/paper-the-security-of-password-expiration/
My attack scenarios are how I would approach it in 2 different ways, 1 as a hacker 1 as a cracker I honestly would first secure myself continual access to the system upon gaining entry, sure you could take the password hashes, but installing a backdoor/trojan etc is much more effective. Even something as simple as a small program that loads the password hashes and posts them online every 2 weeks somewhere for collection.
I still think organisations need to embrace alternative approaches to security while accepting that a users password is going to be weak, and an unlikely method of a security breach. Why continue to annoy and push the users by forcing them to change their passwords?
I know organisations would have to change, to become more “proactive” (too many times I’ve heard IT departments say they want to be more proactive etc). Time-based logins would work for the majority of employees, remote webmail shouldn’t be enabled by default, remote access should be filtered etc… There are so many other approaches to security I feel are neglected because other “easy” options exist that people just assume increase security.
I think password expiration falls in to this category; perhaps 10-15 years ago it was a good approach because hackers/crackers were not as sophisticated as they are today. Many more attack vectors exist today that getting someones password is almost “too much work”.
I mean if I wanted to gain access to a companies security systems all I’d do is build a USB drive with some well named executables and leave it in the target companies carpark. I have not yet worked in an organisation that prevents the use of USB drives.
http://news.hitb.org/content/usb-drives-left-car-park-corporate-espionage-attack-vector
(interestingly after I wrote my previous comment I was talking to a friend who isn’t in IT but works in a large company and I said to him “do they enforce password changes at your work?” “yes” “do you write your password down or just increment the number?” “I increment the number like everyone else”). Because one person is doing this, it along negates the password expiration because all future passwords are predictable based on a single broken hash or compromised account.