Blocking the Most Common Patterns

Password Firewall v7.10 blocks the most common keyboard-based patterns.  Examples include, “qwerty”, “zxcvbn”, “qazwsx”, etc.  The matching is not case sensitive so Password Firewall will catch most use of these patterns as part of password choices.  If a match is found then Password Firewall will block the password choice without a need for performing the blacklist query.  But we don’t want to deny just any password that happens to include one of these keyboard patterns.  That is where our safeguards apply.

Safeguards

Not all passwords containing a keyboard pattern are of poor quality.  Qwerty12345 is certainly a bad choice.  After all, it is in our curated blacklist and commonly tops the Worst Passwords of the Year lists.  But a randomly generated 30-character password that happens to include a case insensitive match for “qazwsx” is likely still a plenty secure password, due to it’s length and randomness.  Because of this, Password Firewall includes length as a safeguard to keyboard pattern matching.   If a password choice that matches a common keyboard pattern is not significantly longer than the pattern itself, then Password Firewall will block the password choice.  Generally, since the keyboard patterns are short (5-6 characters), then the password choice will need to be at least 15 characters in length to be exempted from the pattern-based matching.

But we also include a safeguard to the safeguard.   Before granting an exemption to the pattern matching based upon password length, an additional check is done to make sure the end-user has also included some non-pattern characters in their password choice.  This prevents “clever” password choices based upon keyboard patterns from being exempted just because overall length is good.  This is best understood by example:  “aE8QazWSx72-8uNn3vPR” would be exempted from pattern matching but “QAZ2WSXqaz2wsxQAZ2WSX” would not.

Blacklisting Still Applies

It’s important to remember that once a password choice makes it past the keyboard pattern matching check, blacklist checks still apply. “Qwerty12345password” might make it passed the pattern check, but it’s still a blacklisted password.

Upgrade Today

Password Firewall v7.10 is available for download now.  Upgrades are easy, but you have to be running v7.10 (or later) to gain this additional protection.

The post Password Firewall Blocks Keyboard Patterns appeared first on Password RBL.

So we set out to make a Password Blacklisting service that was “obviously secure.”  A password screening service that had no possibly of ever knowing the password choices involved.  Or the username associated with the password.  Or even the customer sending the query.  A service where customers did not have to extend any trust or sacrifice any security to use the service.  This is what we built at Password RBL.  But the industry came up with a concise way to describe such a service:  “zero-trust.”

For additional details, follow this link to read about how Password RBL’s architecture truly is zero-trust.

TL;DR: Password RBL was “zero-trust” before it was cool.

The post Zero-Trust Before It Was Cool appeared first on Password RBL.

MFA

As we know, Multi-Factor Authentication (MFA) is a great way to combat potential account takeovers or just general bad password hygiene.  Even when MFA is used, Password Blacklisting still makes sense.  But if MFA is not in use, then Password Blacklisting is an absolute must!   Unfortunately, the report found that 52% of people have never heard of MFA.  This makes enforcing strong passwords even more important.  But why is this?  Well, 64% say they have no access to MFA, and another 10% say they do have access MFA, but choose not to use it.

Responsibility

Additionally, the data indicates a significant proportion of people simply do not see themselves as responsible for looking after their workplace’s sensitive information.  Over a third (40%) of the full-time and part-time employees participating in this report considered themselves to be the least responsible agency for their organization’s cybersecurity.  That means that nearly half of your employees don’t think it’s their responsibility to choose a strong password!  This statistic is alarming and makes the case for all businesses to deploy Password Blacklisting in order to prevent users from choosing poor passwords.

Passwords

Speaking of passwords, the report also discovered some alarming, but simultaneously not surprising, statistics on real-life password behaviors.  Only 43% of participants reported creating long and unique passwords for their online accounts “very often” or “always”. However, almost a third (28%) stated that they didn’t do so.  A third of real-life users are knowingly choosing weak passwords!  That’s a big number!

But about the more middle-of-the-road, average password behavior.  It’s still not great.  A majority (58%) of the respondents say they only “sometimes” (30%), “rarely” (18%), or “never” (10%) create long (12 character) and unique passwords.  This is probably because use of a stand-alone password manager application, which would create these long unique passwords, was uncommon, with almost half (49%) of the participants noting they ‘never’ or ‘rarely’ used one.

Not Great.  But What To Do?

The full Cybersecurity Attitudes and Behaviors report (available here) contains lots more information and statistics.  But even with just the few takeaways mentioned above, it’s clear that more work needs to be done.  Deployment of Multi-Factor Authentication would absolutely help, but by 2021, the reason MFA isn’t completely pervasive is because of many real-life problems, including end-user adoption woes, cost to the business, supportability, and definitely incomplete deployments since businesses commonly support legacy systems which have no concept of MFA – or anything other than usernames and passwords, really.

Enter Password Blacklisting – the incredibly affordable and easy to use solution to the bad password problem.  Password RBL has drop-in support for Microsoft Active Directory (and anything linked to AD) and a dead-simple API that can be incorporated into basically anything else.  The return on investment (ROI) of a subscription to Password RBL makes deployment an easy choice – for IT and decision makers.  See our solutions in action and request a free quote today!

The post Cybersecurity Attitudes and Behaviors Report appeared first on Password RBL.

Pipeline Problems

In May 2021, a password-based hack of Colonial Pipeline Co. took down the largest fuel pipeline in the U.S. which led to fuel shortages all across the East Coast.  It was a single compromised password that allowed the attackers to completely shutdown the company and cause devastating downstream affects, including a run on fuel, higher fuel prices, but also a data breach of customer information as well.  If the company had just implemented Password Blacklisting, the poor password choice would have been caught and prevented from use in the first place.  No MFA required.

Supply Chain Problems

Of course we all remember the Solarwinds hack from late 2020.  Again, a single compromised password, “solarwinds123”, was found in data breach data from 2019.  The company’s poor password hygiene allowed a user to choose such a terribly crafted password.  And it doesn’t matter if it was an intern, manager or leader.  A single compromised account spells disaster.  And in the case of Solarwinds, it was not only disasters for Solarwinds, but all of their downstream customers, too.  Once in the Solarwinds network, the attackers were able to change the code of their product, granting access to any Solarwinds customer who installed the latest version – and there were some big customers hit by this, including numerous departments of the US Government and many Fortune 500 companies.

A Simple Solution

The easiest and most cost effective way to combat these types of attacks is to deploy Password Blacklisting.  It’s incredibly easy to do – much easier than deploying MFA.  There isn’t even a requirement to change end-user behavior or provide training.  A subscription to Password RBL is incredibly inexpensive and easy to deploy, adding another layer to your companies security stack.  Check out our solutions and request a quote today!

The post Password Attacks Continue to Cause Major Problems appeared first on Password RBL.

Reason 1 – Exceptions

First off, it is very common that when MFA gets implemented, there will be exceptions for systems/services that just do not (yet) support MFA.  Each of these applications/services are holes in your organization’s security and attackers will find them.  Most MFA rollouts have at least one of these apps/services that still rely on classic username and password authentication.  As many organizations found out the hard way in the summer of 2020, MFA is great, but if your company VPN solution doesn’t use/support it, then very bad things can happen.  Attackers can log into the company VPN, impersonating a real company user.  Once attackers have direct access to the interior of company networks, it is as if the bad guys are freely roaming the isles of the company datacenter.  Nothing good becomes of that!

Reason 2 – MFA Bypass

Another great reason to keep password blacklisting around is that as the prevalence of MFA deployments increases, attackers are changing their ways and are figuring out how to bypass MFA altogether.  There have been numerous high-profile MFA-bypasses in the past year.  A quick google search shows reports on many of them.  But the most disastrous MFA bypass has to be the Solarwinds supply-chain attack announced in late 2020.   In order for the attackers to gain access to the source-code of Solarwinds’ popular Orion platform, they first had to bypass the MFA that Solarwinds had deployed.  Spoiler alert, the attackers were able to bypass Duo MFA and injected malicious code into the Solarwinds source.   The Cybersecurity and Infrastructure Security Agency (CISA) in the US issued an advisory about attackers combining numerous different attack methods, but notably, MFA bypasses.

The Bottom Line

The answer is clear: you should deploy both Password Blacklisting and Multifactor Authentication.  MFA deployments can stress the budget, but whereas the cost for a Password RBL subscription is quite reasonable.  If you do not have the budget for MFA, then Password RBL blacklisting is a perfect first step – providing an effective addition to your security makeup and fantastic ROI.  And if you do already have MFA deployed (or the budget to do so), then you can inexpensively add Password RBL blacklisting for a fraction of the total cost.  Either way, Password RBL is for you!  Check out our Packages for Small & Medium Business or request a free quote if your organization is larger.

The post Got MFA? Good. But You Still Need Password Blacklisting appeared first on Password RBL.

Basic Findings

Out of the 1 billion credentials analyzed, there were only 168.9 million unique passwords in the list.  This means there is a startling amount of password reuse – bad password reuse.  Password RBL specifically blocks these poor and reused passwords.  This prevents Account Takeover Events by preventing users from, knowingly or inadvertently, choosing the passwords that hackers already know and use in password-based attacks.

The most popular password was “123456” – a truly horrible password choice, as this password (or similar ascending numerical variants) has been in the top 10 worst password choices for years now.  In fact, it was so popular that it was 1 out of ever 142 passwords in this dataset!  This password has been blocked by Password RBL since the very beginning of our service.

Password Complexity

Of all the unique passwords in the list, 28.79% were comprised of letters only with 26.16% using lowercase letters only.  Sadly, 13.37% of the passwords used only numbers, which is terrible since there are only 10 characters in the numeric alphabet, making brute-force of numeric-only passwords far easier.  And finally, only 2.04% of the passwords used special characters.

Password Firewall for Windows, specifically addresses password complexity with the Minimum Character Sets Required option.  This allows administrators to choose how many character sets must be present in password choices.  It doesn’t require a specific number of characters from each character set, because it’s only important that the passwords have at least one character from the specified number of sets.

Interestingly, 34.41% of the passwords analyzed ended in a numeric digit (but only 4.52% began with a digit).  This is exactly why Password Firewall has the Password DoubleCheck feature.  It will drop any digits at the end of a password choice and then re-query the Password RBL database with the resulting (truncated) password to see if the end-user has chosen a bad password, but simply added a digit to the end.

Password Reuse

There is plenty more evidence of the bad password reuse happening.  Unique passwords, that are found only once in the dataset, make up only 8.83% of the dataset.  The top 1,000 most common unique passwords from made up 6.61% of all passwords in the dataset.  The top 1 million most common passwords comprised 36.28% of the dataset.  And the top 10 million most common passwords made up 54.00% of the entire dataset.  So an attacker cracking a password database (that did not use password blacklisting) with a wordlist of only the 10 million most common passwords, has a better than 50/50 chance at cracking each password.  This is why password blacklisting is so necessary.

There is diminishing returns in brute-forcing with a larger datasets.  Brute forcing attackers obviously don’t need to.  But, we go even farther at Password RBL.  Our highly curated database currently has over 75 million of the most commonly used bad passwords and is growing every year.  Additionally, we provide a conduit for our customers to simultaneously query the Pwned Passwords database as well.  There is a large overlap in our databases, especially at the top end of the most commonly used bad passwords.  But it is a fairly safe assumption to say that this provides protection from over 500 million bad password combinations, which is more than the total number of unique passwords from this latest analysis.

Conclusion

This analysis confirmed alot of what Password RBL has known for a long time.  People reuse passwords, alot!  And the passwords they are reusing are common and well-known at this time.  These are the passwords you do not want your users or customers using on your network or app/service.

Password RBL provides an easy way to block these bad passwords as well as any custom passwords you want banned, too.  We even provide statistics so you can know if your users are getting better at choosing passwords.  And best of all, subscriptions are inexpensive so organizations of any a size can afford this effective base-layer of security.

The post A Billion Passwords Analyzed; Password Firewall Protects You appeared first on Password RBL.

Active Directory services get extended to cloud services via proprietary directory synchronization tools such as Microsoft’s Azure AD Connect (previously known as DirSync) or Okta’s AD Agent.  In the case of Okta, the AD Agent is a small service that runs on one (or more) servers on-premise, synchronizes directory users into Okta and acts as an authentication relay agent using a method refereed to as Delegated Authentication.

Okta becomes an organization’s central cloud-services authentication hub.  This is where [Active Directory] users authenticate to gain access to the organization’s growing cloud-based services catalog.  This centralization of authentication helps organizations control cloud-service sprawl and therefore the number of places where they can be attacked.  But this also means that the passwords that grant access into an organization’s Okta tenant are even more important to protect.

Okta does have an option for preventing the use of the most common bad passwords.  But not only is this blacklist small, it only protects Directory Users when they choose to change their password from inside the Okta portal (which is a feature that is not even enabled by default).  Most directory users still use plenty of on-premise applications and still use a computer that is joined to the company’s Active Directory.  These users will be changing their passwords against Active Directory, directly interfacing with one of their organization’s Domain Controllers.  Okta’s bad password prevention feature is not involved in these password change events.  This is why you still need Password Firewall for Windows to protect your Okta environment, as well as Active Directory and anything else linked to it.

Not only is Password Firewall’s blacklist far more extensive and our solution more configurable, but most importantly, it catches these on-premise password change (and Admin/Helpdesk password reset) events that are happening directly with Active Directory.  Without Password Firewall’s protection of your on-premise Active Directory passwords, your Okta tenant is at risk.

Check out Password Firewall for Windows.  It’s fast to deploy, super easy to use, and inexpensive, too.

The post Why You Need Password Firewall to Protect Okta appeared first on Password RBL.