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.

Password RBL Unaffected by Log4j Vulnerability

Password RBL is not impacted by this log4j vulnerability because Password RBL does not utilize this library in any systems.

This should not be surprising, since Password RBL has a zero-logging policy.  Thus, Password RBL has no need for a code library that provides advanced logging services.  But it is important for subscribers to know that Password RBL is unaffected by this recent vulnerability and continues to be a secure and easy way to prevent bad passwords before they happen.

Update on Additional Vulnerabilities

Since the original positing of this statement, additional vulnerabilities in the log4j library have been disclosed.  Password RBL remains unaffected by these additional vulnerabilities as well, since Password RBL does not utilize the log4j library at all.

Not a customer?

If you are not yet a customer of Password RBL but are interested in better passwords for your organization, then follow this link to learn more and read about why our zero-trust solution for better passwords really is secure.  Our solutions are easy to use and subscription costs are very reasonable.  Subscribe today!

The post Password RBL Statement on Log4j Vulnerability 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.

New Feature: An Additional Way to Query

This major release all centers around one new core feature – an additional API endpoint that utilizes a customer-provided API Key to authorize connections to the API.  Using this API Key allows customers to query the API from anywhere, without first registering their IP address(es) with Password RBL.  Not only is API Key authorization easier for customers (because there is no extra IP address management task), but it also friendly to cloud-based infrastructure and services that do not necessarily maintain static IP addressing.  But just to be clear, this is a new API endpoint and the existing IP-authorized endpoint is still supported.

A Little History

Previously, Password RBL’s API only authorized customer connections based upon their source IP address.  This was a design decision from the very beginning.  Password RBL has always been very focused on providing password blacklisting services in a zero-trust manner.  A cloud-based password blacklisting solution was new to the world back then, and we really wanted customers to understand that it really is secure.  So we choose to implement customer authorization by IP rather than API key.  API queries entering our service were confirmed to come from customers based on the packet’s source IP.  With the original architecture, by the time the query got passed network checks and load balancing, the API did not know which customer it was coming from (just that it was an authorized customer).  But once we added the Prefix-Query method (where queries only contain a portion of the password hash, not the entire hash), customers had even more assurance that even Password RBL could never determine the cleartext password from their API submission.  This opened the door to reconsidering a feature requested by many customers – API Key authorization.

A Quick Word on TLS versions

This new key-based endpoint is a modern, new method of connectivity and thus, requires modern TLS connections – TLS v1.2 at a minimum.  It is important to note that Windows Server 2008 R2 does not have TLS v1.2 enabled by default.  In order for Password Firewall to run with API Key authorization on Windows 2008 R2, you must update .NET to latest patch release and then manually create some registry entries to enable the use of TLS v1.2.  There are many guides that you can follow.  Later versions of Windows supports TLS v1.2 by default.  Windows 2008 R2 is now End of Life so any 2008 R2 servers should be retired anyways (but we still support Password Firewall on Server 2008 R2 because we would rather you have strong passwords and an old server than bad passwords and an old server).

Download Today!

The latest API is in production and the latest version of Password Firewall for Windows available now,  Head over to our downloads page for the latest software and documentation.

The post New Versions of API and Password Firewall appeared first on Password RBL.

The attack is quite simple.  A regular end-user has a bad password.  Attackers can figure this out in the typical manner – a password spray or credential stuffing attack.  Once they know the credentials for a user account, the attackers perform a scan of the companies public infrastructure to find the VPN device.  They log into the VPN with the compromised credentials and now have direct network connectivity. The attacker uses this recent Netlogon vulnerability to gain SYSTEM level permissions on the domain controller which means that can basically do anything they want after that, because they can create a new Domain Administrator account.

And now with a Domain Administrator account in hand, the attacker can trigger a very thorough crypto-malware attack across the entire organization.  Ransomware with the reduced privileges of a normal end-user account is bad enough.  But ransomware from a Domain Administrator can be debilitating.  Not only can it encrypt important company data, but also system files which can bring down every Windows systems.  Most companies have good backups of servers.  But most companies do not back up workstations.  It could take weeks or months to rebuild or replace all the workstations.

Obviously, organizations need to follow Microsoft’s guidance on patching this vulnerability as soon as possible.  But there has been similar vulnerabilities before, and there will surely be similar ones in the future.  So, organizations should also deploy Password Firewall for Windows to prevent the use of bad passwords that lead to account takeover and much, much worse.

The post Bad Password + Zerologon = Ransomware 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.