Defenses against weak or leaked user credentials

Hackers have bosses. Even during a crisis, they have objectives to hit. A global pandemic has little effect on an industry that is already remote. What we see as a time to come together, they see as a time to capitalize.

Like a burglar walking through a neighborhood checking doors and windows, attackers constantly scan the internet to find systems they can reach. Upon finding them, they look for low-hanging fruit — weaknesses that might gain them access, such as weak or leaked user credentials, unpatched vulnerabilities, or misconfigurations.

In this blog, we’ll focus on defenses against weak or leaked user credentials. The defenses go beyond strong password policies. User credentials are one output of the access control process. Before the user receives their credentials, though, access must be approved, user identity must be provisioned, passwords must be created, and system permissions must be granted. This blog will introduce the elements of a comprehensive access control program.

Comprehensive access control is not a task for the faint of heart. But there are steps you can take today as you mature your program. The detailed information here is aimed at technical folks tasked with securing business networks and applications. You can get the TL;DR by scanning the page for the “Best Practices” bits. If you want the whys and wherefores, strap in and let’s get into it.

Attacking User Accounts

Credential attacks are everywhere. Brute forcing. Credential stuffing. Default credentials. While password attacks are dangerous, you can take simple steps to prevent takeover of your user accounts.

First and foremost, ensure all user accounts employ good password practices. Passwords should be complex. They should never be reused on other systems, and they should never be shared. If you do nothing else to protect your systems, make sure your passwords — especially for high-privilege accounts — are strong, unique, and secret. DO NOT SKIP THIS STEP.

Ensuring strong passwords universally can be a challenge. Even with password complexity requirements, it’s still possible to create guessable passwords. Multiple systems I access require the same username and password to access them. Some accounts must be shared. What are best practices in these cases?

Check out this webinar for more insights on security infrastructure 

Password complexity

A quick search for “creating good passwords” provides plenty of guidance for creating good passwords. But even when following recommended complexity requirements, we still see users choosing passwords that can be guessed in too short a time. Complexity standards don’t prevent such choices.

For example, imagine a password policy requiring 16 characters with at least one capital, one number, and a special character. The policy also requires rotating the password every 90 days. The following password meets that requirement: “Barracuda2020Q1!” And it’s easy to remember.

It’s also easy to guess (or at least try) if an attacker knows the complexity and password rotation requirements. Pen tester friends in the industry tell me they succeed with this sort of guessing more often than not on engagements. Many times, some user’s password that is compliant with the policy is still guessable.

When you take simple passwords and add in leaked passwords — even complex ones — from previous breaches, automated password attacks are successful often enough that they are a staple in the initial phases of an attack.

The best defense against weak or leaked passwords is multi-factor authentication (MFA). When MFA is configured, even if an attacker has found a working username and password pair, the user will be asked to confirm the login and have a chance to deny the action.

Best Practice: A combination of strong passwords and MFA goes a long way to neutralizing password-based attacks.

Password Reuse

Password stuffing attacks take username and password pairs from previous breaches and try them against other services. For example, my username and password were leaked in the LinkedIn breach in 2012. It’s reasonable to believe that many people have tried that username and password combination against every bank site on the internet. It would be a smart thing to try. I’m happy to have wasted their time because that password worked only for LinkedIn. When it was lost, I changed my LinkedIn password and went back to enjoying life — so did everyone else who uses a unique password for every site.

But at work I log into our bug tracking system, our wiki, our source code control system, and lots of others. All with the same username and password. My password manager hates it. It complains that I am reusing passwords. But am I?

Not really. All those systems are tied into our central identity provider (IDP): Active Directory. So, while it may feel like I’m reusing passwords, it’s really only one password tied to a single identity.

A centralized IDP has the added benefit of creating a single place for granting and revoking user access. This feature is critical for effectively limiting the attack surface of your applications.

When many systems are tied into a central identity provider, it becomes even more imperative to enforce a second factor of authentication. In this case, a valid username and password pair will grant access to many systems rather than just one.

Best Practice: Never reuse passwords across services.

Best Practice: In a business environment, centralize your user access with a centralized identity provider such as Active Directory to minimize the number of passwords users need and to centralize revocation of access.

Best Practice: When using a centralized identity provider, MFA becomes essential.

Shared Accounts

Shared accounts are another point of attack because of the number of people who have access to the password. It’s also more challenging to configure MFA on a shared account.

It seems like in 2020 there should never be a need to share user accounts — especially privileged ones. And that’s mostly true. For example, at Barracuda, user access to our public cloud accounts like AWS and Azure is controlled by our corporate Active Directory. If I need access to a specific cloud account, I file a written request to IT who then adds me to the proper security group. When I no longer need the access, I am removed from the security group, and my access is revoked. When I leave the company, access to all systems can be removed by disabling or removing my AD account. This process works well for the vast majority of accounts in our environment.

But every AWS account has a root user established at account creation time. Best practices dictate that daily work is not performed in that account. It’s there as a “break glass in case of emergency” safeguard, such as if our AD integration is broken and regular access isn’t working.

The password for the root account needs to be available to authorized users in the organization. Otherwise, we would risk losing that safeguard if the user with the password left the organization. We follow a similar pattern for managing our servers. Normal business is conducted via individual user accounts controlled by a centralized identity provider (IDP). Emergency access is gained using the system root account.

Because of the sensitivity of these accounts it is very important to control access to those credentials and to log and monitor all use of those accounts. Their usage should be very rare and should raise an alarm.

Best practices:

• Minimize the use of shared accounts


• Store shared passwords securely


• Limit access to shared passwords


• Monitor and alert on usage of the share accounts


• Review access regularly


• Rotate the password when users with access leave the organization

A Note on User Provisioning

Whether you’ve configured a centralized IDP or employ the user management built into your applications, protecting your business extends beyond just preventing unauthorized logins. A comprehensive access management program has several additional components.

There should be well-defined processes for requesting and approving access to systems, including guidance that helps limit unnecessary access and implements a system of least privilege. The fewer people who have access to a system, the smaller the opportunity to gain access via a compromised user. A process should be defined for each system storing or processing sensitive data, and that process should be reviewed by your compliance and data privacy teams.

Typically, the access approval process includes approval from someone on the requestor’s management chain. For an approval process to be effective, it’s important to train approvers in the processes and criteria for requesting and granting access. The training should include discussions of the data processed and the impact an authorized user can have with access to the data. Similarly, system owners — the people who provision new accounts — should be familiar with the requirements defined for gaining access, and they should be empowered by management to deny access requests when the requirements for access are not met.

Administrators should be clear on how permissions within the system (authorization) are managed once access (authentication) has been granted. Are permissions managed by membership in an AD group, or are they managed within the application? For example, permission to log into Salesforce may be governed by membership in a specific AD group, but the permissions the user has inside Salesforce may be defined by the Salesforce application itself independent of your AD groups. Keeping in mind the possible disconnect between authentication and authorization and then mapping out where permissions are defined is essential for ongoing access reviews. Review of AD group membership is often insufficient.

Periodic access reviews are often overlooked. Here is a case where monitoring can help. Do all the people who have system access use it? If not, it’s a good practice to remove unused access. If someone hasn’t used their access for 90 days, consider revoking it. If they need it, you’ll hear the screams. But make sure your access-granting processes account for a previously authorized user regaining access if it’s been removed. The purpose of this process is to remove access that people don’t need — not to prevent people from doing their jobs.

Have a plan for revoking access quickly. Whether it be a termination of someone’s employment or a compromise of their account, having a clear procedure for revoking a person’s access across all your systems is an essential part of an access management program.

And finally, centralized logging of user access events makes it possible to monitor for unusual user behavior.

Best practices: A comprehensive access management program will:

• Define processes for getting access to system


• Train system owners and access approvers in the access control processes and requirements


• Understand where system permissions are defined


• Log and monitor user behavior


• Review both access patterns and user permissions on a regular basis


• Remove access that is no longer needed


• Have a plan for revoking access quickly

Summary

The products and services we use are now distributed all over the world in a myriad of networks beyond our direct control. The builders of those products and services provide controls to ensure that your information is secure. The industry provides best-practice patterns. But your vendors can’t do it all for you. Hopefully, this post has outlined some steps you can take to maximize the effectiveness of those controls and keep your customers, users, employees, and systems safe.

Check out this webinar for more insights on security infrastructure