Threat HUNTing Platform
Credential Risk Assessment and Remediation
ORKOS: Preventing the 9 steps to domain collapse
R9B understands the cognitive aspects of cyber operations. Our curriculum provides the hands-on technical skills students require to attain a variety of advanced cybersecurity qualifications. We instill the knowledge, skills, and abilities necessary for our students to defeat the adversary. Below are our available courses. Please check back often as our course offerings are updated regularly. Government organizations, please contact R9B directly via training@root9B.com for pricing and purchasing information.
At the end of my last post, I said my next topic would be event logs, but when I sat down to write, my brain said, “Nope! Try again next time!” So, I am going to delay that entry, and instead, I will discuss some rather unusual claims that Microsoft has made about passwords.1
In June of last year, Microsoft published a paper rejecting some well-known, recommended password practices. Specifically, the report encouraged people to stop enforcing the following requirements for normal user accounts (not sensitive or administrative accounts):
Wow, those are some big claims! Microsoft has challenged everything the Security+ and CISSP certification courses have been teaching. However, I must say that I agree with them. (Hang tight, folks. I haven’t lost my marbles!) I feel that many of us security professionals tend to focus on making things as secure as possible without thinking about the burden to the end user. I also believe end users will respond to security practices just like any law. If laws are too complicated to follow (regardless of their intent) or don’t serve an evident purpose, individuals will find ways to meet the bare minimum or circumvent the laws entirely.
Think about this. We all have an Edna who has been working in Human Resources for 1,000 years, but we absolutely adore her. Any time you talk to Edna, you have a butterscotch and exchange stories about your children and her grandchildren. One day, you decide to try educating Edna on the importance of creating strong passwords. After hours of persuading her that her password can’t have any of her kids’ names, her pet’s name, or the name of her favorite Bingo hang-out, you give up and let Edna do what she wants. We may not like it, but this situation plays out much more often than we’d like to think. Is it really worth the struggle to make sure that every employee on every account has a traditionally strong password? In my opinion, no.
Let’s look at this problem through a more technical lens. What are most the common attack vectors for credential theft? In a separate article, Microsoft lists five common attack vectors that target passwords2:
While this list was created in 2007, it is still relevant today, a decade later. The Microsoft article published last year (2016) has added a couple items to that list (but removed none of the original items):
Based on these two lists, strong passwords only protect against three attack vectors: brute force attacks, guessing based on user information, and bulk guessing. Every other method deals with stealing credentials, such as enticing the user to enter their password or some other tactic that doesn’t require guessing the password. Why do we create complicated password policies that only defend against three specific attacks? The fallout from this is that users will leverage bad password practices to meet these stringent password requirements, thus undermining the security we were trying to achieve in the first place. Remember, when it comes to security, we must always take into consideration how end users will behave.
With that said, let’s look at each of the three Microsoft claims:
Microsoft states that when longer passwords (10 characters or more) are enforced, users tend to use unsecure behaviors to meet the long password requirements. Users will create passwords like “catdancecatdogrundog” or “password123456” to meet the length requirements of the organization. Sure, longer passwords will deter brute force attacks against hash cracking, but that isn’t the only way to attack a password.
The longer a password requirement is, the more likely it is that end users will try to fill their passwords with fluff, use the same complex password for everything, or develop patterns that a machine can successfully guess. If poor Edna has to create a 16-character-long password, she is simply going to repeat the name of her favorite character from Gone with the Wind twice.
While I do understand Microsoft’s point, I’m not convinced that this is a best practice for end users. The white paper suggests using eight characters as a minimum length, but password cracking software is getting faster and cheaper. Despite Microsoft’s recommendation to keep passwords under 10 characters, I believe setting the minimum password length to 12 characters is an acceptable risk. This is not too much to ask of the end users, and those two extra characters can add just a little bit more entropy to fend off modern crackers.
Next, Microsoft recommends nixing the requirement for multiple character sets. In other words, they recommend end users NOT be required to create passwords with a combination of uppercase characters, lowercase characters, numbers, and/or non-alphanumeric characters. At first glance, this sounds pretty strange. Requiring the use of those combinations, of course, will strengthen the password against brute force attacks and password guessing. However, let’s revisit Microsoft’s list of common attack vectors: malware, data breaches, keylogging, and, phishing. None of these attacks require an adversary to crack the password at all. The strongest password in the world cannot protect against theft. So, why enforce the creation of complex, hard-to-remember passwords when doing so provides no protection against the most common type of attacks?
Furthermore, requiring the use of special characters encourages individuals to use repeatable patterns (“!@#$” or “%^&*”) or character replacements that seem clever but really aren’t (e.g. using “!” for “L” or “@” for “A”). At this point, we are actually helping attackers crack a password as modern password crackers will analyze for these occurrences.
As before, this claim seems a bit out there but makes sense once you think about it. Microsoft recommends that end users NOT have expiring passwords. We security professionals have been taught that passwords are perishable, just like milk, and we need to make sure we keep rotating them out. Well, more often than not, end users often update old passwords rather than creating new ones. For example, if Edna has the password “Clarance17”, her next password most likely will be “Clarance18” or some derivation of another one of her grandchildren’s names.
In a real-world example, our pen test team compromised a server administrator’s password using this exact technique. They compromised an account’s password and informed the client of what they did. The administrator reset his password, then our team compromised the account again, because the administrator had only incremented the password by one (e.g., if his password was “Tuba34”, he changed it to “Tuba35”). Once again, this places a burden on end users while failing to achieve the intended goal of expire passwords. So, why do security for the sake of doing security?
So, What Now?
Let me say again that these guidelines are for your average end user, not administrators or high-value accounts. Those that have access to sensitive areas of the network should meet higher standards on their authentication methods. They must have passwords that are longer, expire, and meet the current industry standards. (Remember, we need to trim the fat of excessive security practices that give us little added value. We must implement lean, flexible security policies which allow us to defeat modern threats. The status quo has allowed a huge number of data breaches in the last several years.)
Now, based on Microsoft’s recommendations and traditional security precautions, I’ve outlined password requirements for both general end users and privileged accounts.
For end users, follow these general guidelines (unless regulatory compliance requires differently):
For privileged accounts, follow these general guidelines:
Smartphones are a wonderful thing. Even Edna knows about Snapchat and how to Facebook with her grandchildren. Another great thing with smart phones is that multifactor authentication (MFA) apps are becoming a norm. MFA is not a part of every website or login mechanism, but it is rapidly gaining popularity.
MFA is a security feature that requires an additional means of authentication when using a username and password to login to an account. This can be an app on a phone, a security token, a biometric code, a secondary e-mail confirmation, or some other means of unique identification. Most of these mechanisms are simple enough for Edna to use.
Currently, the two most common types of MFA come in the form of text messages and phone apps. During a login attempt, you will receive an authentication code via text or the app which must then be submitted back to the MFA provider alongside your login credentials. For example, when I log into LastPass on a computer or device that I have not listed as “trusted”, LastPass will send my phone a text with a temporary code. I must provide LastPass with that code in addition to my username and password.
The benefit of MFA is that even if a password is stolen, the attackers will still need the secondary authentication mechanism to authenticate in (in my case, they would need my physical phone). This provides a robust countermeasure to most of the attack vectors listed in the first part of this article.
It may seem like a daunting task, but we must educate end users. Frankly, we have forced them to comply with overbearing rules to the point that they simply want an easy password that satisfies these rules. This is how they come to believe that “BasketCase123!!!” is a secure password. If we are to relax some of these requirements, we need end users to work with us in protecting the network. By educating them, we give them a personal stake in the security of the network they use. We become their allies instead of their antagonists.
root9B’s Senior Research & Development Scientist, Matt Weeks (https://twitter.com/scriptjunkie1), has some advice on things end users should do when dealing with passwords:
Use password best practices both at home and at the office. Many times, people can be compromised at home which will leak information that can lead to a compromise at their offices.
Use unique passwords for everything. Many times, a breach at one website will lead to other compromises, because people reuse the same password or password pattern for everything. As such, all my bank websites, social media, and tech community websites have unique passwords which means I’m not reusing those passwords at work. (This is a good reason to have a password manager.)
When passwords can be handled by a password manager, take advantage of the opportunity. Password managers can track and create strong, unique passwords. Managers always do a better job of creating secure passwords than humans can. This allows you to have unique passwords for all your website logins and without worrying about memorizing them. This also helps you avoid reusing those passwords at work.
Check to see if you have been a victim of a breach. Many people sign up for random things on the internet and never think twice about it; however, there is a good chance they used their “go-to” password when signing up. Therefore, after breaching any one of these sites, an attacker could easily breach any of the other websites using the user’s same username and password.
With looser password requirements, you can change the way you create passwords. It is better to focus on length than complexity and patterns. In fact, complexity and patterns are what have gotten us here in the first place. Strangely, a password like “I like to Sing in THE shower with my Radio” is infinitely stronger than “Shower$$98”. Now, I am not saying that having such a simple passphrase is the end goal, but it is a start. Remember, we are shifting a paradigm, and it will take time for everyone to understand this new philosophy. (Future passphrases can be strengthened by using special characters and numbers, just like complex passwords.) If Edna can use her favorite quote from Gone with the Wind to login to the domain or company-approved password manager, that will serve her much better than a traditional, complex password will.
These are some great guidelines to follow. To add onto the points above, here is a website I use to check if my accounts have been compromised.
Remember my first entry about “getting good”? We system administrators need to make sure that our defenses are in place. We must ensure our devices are in good health, confirming that all patches and host-based security products are up to date and continuously adapting our security strategies as threats and technologies evolve. When Edna clicks on that phishing e-mail, will the other machines near her be able to protect themselves?
(If you have not already done so, I encourage you to go back and read the previous posts in this series and see if you can incorporate the outlined security procedures into your environment. This whole series revolves around how your machines can defend themselves against compromised machines and lateral attacks.)
I know some of these guidelines go against the grain; however, I believe there’s value in balancing security with ease of use. In the grand scheme of things, we use computers to make our lives easier. If the research shows that implementing overly-complex password requirements does nothing for your end users and network, then why do it? Even if you disagree with Microsoft’s philosophy, please look to the recommendations about protecting your credentials. Things like MFA and educating users will still tremendously help protect your accounts. Whichever approach you choose, remember that while your aim is security and your end user’s aim is ease of use, the ultimate goal is to find the proper balance between the two.
Until next time folks!
BACK TO NEWSROOM