Password Firewall Blocks Keyboard Patterns

PasswordRBL Staff — Mon, 03 Jul 2023 03:35:40 +0000

Password RBL has released the next version of Password Firewall. This is version 7.10 and builds upon the solid foundation of previous versions, but it also adds a new feature that has been requested numerous times by customers and prospects. Password Firewall now blocks common keyboard patterns in password choices even if the exact password permutation that includes the pattern is not blacklisted. We have also included a few safeguards so Password Firewall doesn’t make choosing a new password overly burdensome on users.. Continue reading for details of how it works.

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.

Why You Need Password Firewall to Protect Okta

PasswordRBL Staff — Wed, 01 Jul 2020 18:32:32 +0000

Many organizations are in the process of moving applications to cloud-based service offerings. This includes big, well-known services like productivity suites Office 365 and G-Suite, and point-solutions, such as online meeting services and external file storage/sharing services. But as companies continue these moves, they retain their core on-premise infrastructure because moving completely to the cloud is more difficult than it seems. Plus, there are always good reasons to keep some servers/services on-premise. The most popular on-premise service that is retained is Active Directory, since it is the core directory service that everything is built upon in a Microsoft-based network.

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.