Email Phishing Protection Guide – Part 13: Update Your User Password Strategy – Now!


The Email Phishing Protection Guide is a multi-part blog series written to walk you through the setup of many security focused features you may already own in Microsoft Windows, Microsoft Office 365, and Microsoft Azure. By implementing some or all these items, an organization will increase their security posture against phishing email attacks designed to steal user identities. This guide is written for system administrators with skills ranging from beginner to expert.

Introduction: Email Phishing Protection Guide - Enhancing Your Organization's Security Posture

Part 1: Customize the Office 365 Logon Portal

Part 2: Training Users with the Office 365 Attack Simulator

Part 3: Deploy Multi Factor Authentication (MFA)

Part 4: Deploy Windows Hello

Part 5: Define Country and Region Logon Restrictions for Office 365 and Azure Services

Part 6: Deploy Outlook Plug-in to Report Suspicious Emails

Part 7: Deploy ATP Anti-Phishing Policies

Part 8: Deploy ATP Safe Link Policies

Part 9: Deploy ATP Safe Attachment Policies

Part 10: Deploy and Enforce Smart Screen for Microsoft Edge, Microsoft Internet Explorer and Google Chrome

Part 11: Monitor Phishing and SPAM Attacks in Office 365

Part 12: Discover Who is Attacking Your Office 365 User Identities

Part 13: Update Your User Identity Password Strategy

Part 14: Prevent Brute Force and Spray Attacks in Office 365

Part 15: Implement the Microsoft Azure AD Password Protection Service (for On-Premises too!)

Part 16: Disable Office 365 Legacy Email Authentication Protocols

Part 17: Control Application Consent Registrations in Microsoft Office 365 and Microsoft Azure

Part 18: Increase Security with Microsoft Secure Score

Part 19: Email Phishing Protection Security Checklist

Part 20: Recommended Security and Anti-Phishing Training from Microsoft Ignite 2018

 

Part 13: Update Your User Identity Password Strategy

Earlier in this blog series, I highlighted how often the Office 365 identities in your tenant may be attacked by providing steps to view the information. While I also outlined in Part Three of this series how important and strongly recommended it is to enable Multi Factor Authentication (MFA) for all your users, what if you do not yet have this feature in place? What if your organization has not yet embraced MFA and instead has chosen to continue with a username and password approach? How can this strategy be enhanced to increase security?

For decades, the strategy about password policies has included items such as:

  • Change a password every 30 days
  • Require complexity in passwords
  • Force passwords to be 9,10, or more characters in length

What if I were to tell you that these are no longer recommended based on research done in recent years? Yes, this was a bit of a shock to me when I first started looking into this as well. After all, this is how password policies have been set in my 25+ years of experience in system design and administration. With new threats evolving each day, it is imperative to the security of your organization that you understand why the policies mentioned above (while still better than nothing) are no longer recommended, as well as what is now recommended and why.

Before we get into recent research about passwords, let's look at how people have been using passwords for years. Consider some of your first uses of computer passwords. Perhaps it was for your first CompuServe account, Prodigy account, or perhaps a Blockbuster account. You had a username and password in that former age of dial-up modem Internet connections. Chances are you used something simple to remember. For example, suppose your favorite animal was a lion - so you had a password of lion on these first types of accounts. As time went on, you signed up for more accounts on your favorite travel website, for your local grocery store, your favorite hotel chain, and many more we can all identify with. Chances are, that same password or some variant of it is still being used on modern websites and for your work account. Perhaps it evolved to Lion with a capital L, or Lion5 because you are incrementing numbers, or Lion091879 because that is your birthday, or perhaps Lion091879!# because your employer or your bank website now requires special characters in a password.

Now consider your username at work. It is probably some variant of your first name and last name. Don Smith's username could be Dsmith@domain.com or DonS@domain.com or Don.Smith@domain.com. Something that is common and easily guessed.

As a security professional reading this, you may know better than using a password strategy like the one outlined above. But keep in mind, your users are not nearly as concerned with network security. They are likely doing the minimum required to satisfy password requirements you have had in place for years. And, they are using the same or similar password on your network for every other personal account they have so 50 different passwords do not need to be remembered. We are all human and will try to keep things simple.

Now consider an email phishing attack and then the logon attacks you now see after following the steps in Part 12 of this blog series.

Let's say an email phishing attack was successful and a user entered his/her username and password. The attacker was able to logon to this identity because you did not have MFA enabled (hint: enable MFA). Although you were able to quickly identify the breach and force a password change on the account before any apparent damage was done, the attacker was able to get a few key pieces of information for a new targeted attack:

  • The user who fell victim to the phishing email entered a username using the format used throughout your environment. The attacker now knows this format, providing a key piece of information.
  • The attacker was able to harvest your user directory. He or she now knows the username and email address of everyone in your organization. Perhaps he or she knows the job titles of each person as well if that field is populated in your directory, including individuals who are managers or part of the executive leadership team. Algorithms can now be adjusted for a spear phishing attack against these high value identities with a much higher likelihood of success.

Although the attack and breach was quickly identified and remediated, the attacker can now launch a more targeted attack. Certainly the attacker will continue with an email phishing campaign, but with detailed information now known about your organization the attacker can be much more targeted. Consider the attack scenarios that can now be used:

  • With a directory of your users now in the hands of an attacker, names can be researched on social media sites to find out more about each person. Algorithms can then be adjusted to include passwords that may include (using our example above) your favorite animal with a combination of special characters and capitalization. If you can think of the potential password combinations, the algorithms are designed to try them as well. This type of attack can go on for weeks, months, years, but the probability of a successful password guess grows higher each day.
  • With additional information learned from social media sites about your users, an attacker could determine where each user has other accounts. Although your organization may have fortified its network defenses in various ways, consider this: 'have these social media sites done the same?' An attacker could start logon attempts at these social media sites using the user email addresses discovered in the original attack and again start to guess passwords there with information now known. A successful password guess on one of those sites is now just another clue to a successful password into your organization. If an attacker successfully guessed you are using Lion42 as your password in a social media site, algorithms can then be further fine-tuned to try variants on the identities used at the primary attacker's target.

The list of these scenarios goes on and on. Remember that these attackers are smart, very smart. This is about money to them and this is a business many are running with a lot of great resources and intelligent software developers. A nation-state sponsored attack has even more, almost unlimited, resources. They all have all the time in the world to successfully guess user identity usernames and passwords. With each additional data point(s) known about an organization, the easier it becomes for a successful breach to happen.

A New Password Strategy:

With all of this in mind, what can you do? First, keep in mind that these types of attacks are not just for cloud identities, but for any identity hosted anywhere - on-premises or in any cloud vendor environment. Also consider that cloud environments gather attack intelligence from millions of ongoing attacks and use them to help fortify and adjust the security of the environments. For Microsoft, we see more than 10 million attacks involving passwords each day (reference). This is far more telemetry than any on-premises system can provide and far more than most other vendors can gather. The information is analyzed and mitigations quickly enabled, making a cloud environment the safest infrastructure available for your organization and data. See more information about the Microsoft Intelligent Security Graph here.

Microsoft Research has published a detailed whitepaper describing the volume and types of attacks Microsoft sees and learns from each day. These attacks never stop and are only growing. I recommend you take a few minutes to review the research and recommendations in this whitepaper. Then, I recommend you implement many, if not all of these recommendations in your organization. Remember that you cannot simply enable these recommendations. You will need leadership support, a communication plan to your users about why you are making this change and what they can expect, and then plan how you will test and pilot these new policies.

The first part of this effort is often the most challenging - gaining leadership support. In your presentation to leadership, use the telemetry in the Microsoft Research whitepaper AND collect your own data from Part 12 in this blog series. Make your presentation real with data about attacks your organization has against it every day and remind your audience that a breach is just a user click away from a well-crafted phishing email.

From the Microsoft Research whitepaper on password guidance, below is advice offered for policies to enable in your organization using both Azure Active Directory and Active Directory:

1. Maintain an 8-character minimum length requirement (and longer is not necessarily better)

2. Eliminate character-composition requirements

3. Eliminate mandatory periodic password resets for user accounts

4. Ban common passwords, to keep the most vulnerable passwords out of your system

5. Educate your users not to re-use their password for non-work-related purposes

6. Enforce registration for multi-factor authentication

7. Enable risk based multi-factor authentication challenges

Be sure to review the recommendations above, the data provided in the Microsoft Research Paper, data on attacks against your Office 365 identities each day, steps provided in the Email Phishing Protection Guide, and then develop a new strategy for your organization designed to protect your user identities. Keep in mind that email phishing is one of the newest, most popular and growing types of attacks against your organization today. You must get ahead of this threat, maintain your awareness of new attack vectors, and evolve your security posture accordingly.

An Even Better Strategy - Eliminate Passwords from your Organization

As you evaluate your current password policies and consider a modern strategy, also consider that the best way to protect user identities is to work towards eliminating passwords altogether. This sounds like another strange concept to introduce, but it is something Microsoft has been working on to help provide even more security for user identities. Below are a few blogs with more information about this strategy.

Building a World Without Passwords

Implementing Windows Hello

Comments (0)

Skip to main content