Mon. Sep 28th, 2020

Binary Blogger

Are you a 1 or a 0? News, Thoughts and Reviews

Password Policies Need To Focus On Complexity, Not Forcing Frequent Resets

5 min read

photo-3Passwords are the weakest link in security, aside from the actual people. The industry wants to find a way to get rid of passwords but the users’ ability to adopt the change is the obstacle. Yet we continue to have passwords and the policies around them that are lazy, weak, and most departments turn a naive eye to it. Password polices is where the balance of ‘convenience’ and ‘security effectiveness’ starts.

In the traditional model security experts, framework documentation, regulatory rules state that you must force passwords to change regularly. Average is every 90 days. So once every three months users are getting bugged to come up with a new password to remember and break an operational routine that they have built for themselves. Forcing password changes is what the ‘rules’ state so we have to do it, right?

I stand in the growing voice that rather conforming to the presumed normal practice, enhance other areas that will make you more secure. The standard practice of forcing passwords to reset in a corporate environment frequently (60 or 90 days on average), in my professional opinion, makes your accounts weaker which in turn makes the environment security posture weaker. The reason behind this is the same for all security initiatives, the people. The people are the reason.

Let me explain.

Chances are if you are reading this post you have IT and security knowledge and experience above and beyond the normal person. You understand it, you get it, and you in theory are more secure by training than anyone else. You are not the problem (I hope not). It’s Jane the receptionist or Bob the accountant or Pat in the call center. They do not have the training and knowledge we do. They aren’t thinking about security day in and day out like we do. By nature when they are asked to change their IT habits every two or three months they inherently get lazy. Studies and breach data dump shows that people are not good at creating good passwords. When they have to create 5 or more in a year period their choice won’t vary much from password to password. Most will use a common formula when they change it, a core word or string will be the same but they will change the las two numbers. Binary123 then Binary456 then Binary789 and so on. From a security standpoint this practice misses the point of changing the keys.

When you tack on overly complex policies your rate of people writing the passwords down, putting them in a note on their phone, etc… increases. Just because the policy makers can handle the complexity doesn’t mean the non-technical employees can. If they can they will sidestep or minimize anyway they can to make it easier for themselves. Most simply don’t care enough or know enough to care.

The concept behind change practices is to slow down hackers that get access to the password hashes. It’s a a legitimate attack vector but in today’s world it’s not a big of a deal as it was in the past. It’s far easier to socially engineer an admin account than to do the hard cracking of hashed passwords to get access. Chances are if a hacker gets into a system deep enough to get at the hashes, they already have all the elevated access and you are pwned anyway. Changing passwords just ensures the hashes change but it only slows hackers down it really doesn’t stop anything.

What is far more effective long term is to reduce the amount of password changes from every two months to once or twice a year. However, the only trade off is you MUST increase your password complexity rules to compensate. The best approach to avoid what I mentioned earlier is to not increase the minimum length from 8 to 12 but move to passphrases. Minimum lengths of 20, must include spaces, train the employees to shift their thinking from a complex string to a easy to remember phrase. Using their favorite movie quote, song lyric, motivational quote or even a joke is superior than a shorter complex string. Extending to passphrase does two things, the first is the users can remember it far easier than a complex string like Binary678#!. The second is that now the ‘password’ stored is astronomically more complex to brute force and it’s near impossible to run dictionary or wordlist attacks on it.

“I’ll make him and offer he can’t refuse” or “Binary789” ? If you simply remember Godfather you will be less inclined to forget your passphrase as the human mind is far superior to remember through association than straight ‘data storage’.

I found a webpage that calculates how long it would take to crack your password. I ran the two mentioned here –

It would take four days to crack Binary789. Four days, that’s nothing. The password Binary789 meets the majority of corporate password policies, it’s at least 8 characters long, has one uppercase and numbers.

Screen Shot 2016-03-25 at 10.17.24 AM

Running my passphrase “I’ll make him an offer he can’t refuse” shows that character complexity has nothing on length.

Screen Shot 2016-03-25 at 10.17.46 AM

By changing to a complex password that lives longer will make for a far better user experience for the employees, reduce hold desk calls/cost and still keep you secure if not more so because you will have better password discipline with the users. The password change frequency is good in theory but the people that actually have to do it make it weaker than leaving a true strong password alone for longer time.

Here are the most common passwords, according to breach data dump analysis, from 2011 to 2015. People cannot be trusted they will gravitate to the bare minimum of the policies in place.

Don’t think harder, think about security challenges smarter and through creativity you can make your environments far more secure while at the same time making it easier for your users.

Remember, your password complexity will never stop a successful phishing attack. That’s a different post for another day…

End of line.

Copyright © All rights reserved. | Newsphere by AF themes.