Password1, Why is this still a thing?
It regularly makes an appearance in lists of the top 20, 50 or 100 worst passwords, has lowercase characters AND uppercase characters. It even has a number and is over eight characters long. Password1 is clearly one of the greatest passwords ever conceived, which is why so many people keep choosing it.
Over the last few years, I’ve been noticing the same thing again and again. A business may take security seriously, they may try to do everything right, they may have a team who adore patch Tuesday and can’t wait for those sweet, sweet updates, but given a userbase of a couple hundred or more, I can often just try Password1 and gain all the access I’ll ever need.
This is something which is often the first link in a chain of issues that can lead to the complete compromise of a business, so why does this keep happening given that anyone you ask would likely agree that Password1 possibly isn’t the greatest achievement of the modern age?
Well some people believe that having complexity rules enabled would safeguard them against this, however typical complexity rules only require, three of the following, uppercase, lowercase, digit or special character. And, the minimum length requirements are often never configured beyond eight characters. Password1 fits snugly into this category.
Many Password1’s seem to be a relic from user accounts which have been made in a time before time, where complexity rules didn’t exist and passwords never expired. These accounts have often been forgotten about and are left waiting for some devious individual to take advantage.
A support team might deal with a number of password reset’s every day and for the sake of convenience default over to giving out a standard Password1 under the assumption that it will be changed immediately, but often isn’t.
Then there is the person who thinks that it doesn’t matter, they will never be the subject of attack or that nothing important will be accessed if they are. Although given the vast majority of exploits and access attempts are automated and not targeted at any one individual this reasoning doesn’t really hold up.
For whatever reason it exists, Password1 does exist, and the end result is still the same.
So, what is the result? What can I, the innocent penetration tester, upstanding gentleman of the internet, do with this information? Let’s take a typical example of a business using OWA and a remote access method such as Citrix. Now, with OWA there is a method of enumerating a list of valid user accounts which essentially boils down to, submitting an incorrect username takes longer for the server to respond than a valid username.
There are more detailed write ups already available for this type of issue, so I’ll leave out the full explanation.
Since, domains tend to follow several username formats, such as ‘firstname.lastname’, ‘initial.lastname’ etc. its usually not too hard to determine what this format is going to be and create a large list of potential usernames. To be honest, most of the time a little bit of Googling or searching Linkedin is enough to get some example emails and work from there.
So now I have a large list of potential usernames I can submit each one to my target OWA portal, with the greatest password ever invented, and see how many hits I get. I also have the means to filter out any incorrect usernames, meaning any successive runs will become quicker and more targeted.
Now this process can take some time, and thankfully there are already a range of automated tools to handle the heavy lifting, so I can simply plug in the settings, hit enter and check back in a few days to see how I got on.
Although this isn’t an absolute guarantee, for any business the likelihood of this being successful will increase as more user accounts are created. Given any business with a couple hundred accounts, the probability of this being successful becomes more and more certain and, unfortunately, it only takes one.
Once that account is found I can jump straight over to the Citrix logon portal and try to boot up an access point on the client’s internal domain. With this I could potentially access secure information, extract documents or look for ways to escalate my access privileges.
Now this is one starting point which has been achieved way too many times, but similar techniques could also be targeted at Wireless Networks, Web Applications, Internal Networks, Databases and a whole range of other login portals.
Sometimes the issue doesn’t necessarily need to begin with your business. Many other businesses have experienced a breach which resulted in usernames and passwords being exposed. And all too often people choose to use the same login details in multiple locations. Meaning, that the last, or the next breach you hear about may inadvertently expose login information for your business.
So, what to do? Well there are several things that could be done to help increase complexity requirements and ensure that user accounts are well managed.
The Policy Approach
Regularly reviewing all your existing user accounts and disabling or removing anything no longer required is certainly a recommended process. This is a good practice to ensure that old service accounts or test accounts are no longer active in addition it can help to identify users who have multiple accounts associated to them and remove anything no longer necessary or accounts which have been forgotten about over time.
Implementing a good company policy for choosing complex passwords and educating users on the dangers of choosing bad passwords can certainly help drive the point home and sending regular and varied reminders regarding the issue can help make sure people don’t fall back into bad habits.
Ensuring a fairly regular password reset policy is another approach to consider, however it's important to understand the balancing act with this, as it is often part of the reason that weak passwords are chosen. If for example passwords are reset too often it results in easy to remember options, and partly why if Password1 fails I may consider Password2, Password3, Password4.
Resets being done too regularly is also a reason that many common password choices become months of the year or seasons. Ensuring complexity should ideally put a stop to anything too easily guessable, and then resets should be considered based upon the enforced complexity rules and the theoretical time it would take to crack a password of such complexity. Although, if you do read any news of a data breach exposing user accounts and passwords, it is worthwhile conducting a password reset of your own to ensure that there isn’t any overlap that can potentially affect your business.
The Technical Approach
While each of these solutions can certainly help, without technical enforcement to back it up, it may not be the concrete solution you require. So, for added complexity that cuts out some of the weaker passwords increasing the minimum password length can help, however you may find that Password1 becomes Password123 and we’re right back where we started, so don’t consider this as the silver bullet to solve all your problems.
There are some third-party solutions which can integrate into your systems. These can increase complexity rules or disallow passwords which contain certain key words featured on a blacklist. This can be incredibly useful for disabling some weak and common choices but will likely come with some additional running costs.
Even with this solution, relatively weak passwords could still slip through the cracks. Although it wouldn’t be the obvious choice, it may still be possible to determine a weak password given a handful of guesses and this is an unfortunate consequence of any traditional login system using a username and password. People make bad choices and pick the easy simple to remember option.
The downside of technical enforcement is that even if you manage to eliminate every option for a bad password and truly enforce complexity, you’ll likely see an increase in people writing their passwords down, or constant complaints about locked accounts and not being able to get any work done.
In order to accommodate increasing complexity and avoid these kinds of issues, a password management solution might be an option to consider. This can handle the difficulty of remembering multiple random passwords and store the information using a secure encrypted method, providing you don’t use Password1 to access the password manager, it should be able to allow for increased complexity without some of the headaches that come with it.
While a good solution would be a combination of both policy and technical enforcement one of the few ways to truly account for bad passwords is to take away the dependence on the password itself. For this we have our salvation, which is to implement a two-factor authentication system.
This removes the dependency and reliance of users picking strong passwords. Although this can also come with an additional cost, it is one of the most sure-fire ways of removing weak passwords as a security threat. Given a large enough set of users I would not stop at Password1 checks, I would keep going until I find that one weak account. Now, for the innocent, upstanding gentlemen of the internet, these efforts are limited to the time schedule of a security assessment, but for an actual attacker this type of attempt could run indefinitely, and sooner or later, even a fairly complex password could be compromised.
So, while I’m not trying to say that every single authentication system you ever use should rely on two factor authentication, it is important to take a considered look at each of the multiple systems you do have in place, imagine a worst case scenario for that systems compromise and determine if it's time to implement something a little more secure than Password1.