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.

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.

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.

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.

While these recommendations are specific to Windows/Active Directory and Password Firewall, the same concepts can be applied to our API customers protecting a website or app.

Password Policy settings:

• Change the AD password policy to be a single, easy to understand, policy for the whole organization
• Set a longer minimum length requirement (commonly 10 or 12 characters)
• Enforce Password History of 24 (so people cannot use a previously chosen password)
• Minimum Password Age (typically 1 day to avoid people continually changing passwords to defeat the history requirement)
• Complexity requirements disabled (use a Password Firewall feature instead)
• Maximum Password Age is increased (commonly 180 days or 1 year)  <- end-users love this!

Password Firewall settings:

• Enable Required Character Sets option (commonly 2 or 3) – this replaces the AD password complexity requirement
• Populate and use the custom blacklist feature (optional)
• Optionally also query the Pwned Passwords blacklist (in addition to the Password RBL curated blacklist)
• Enable Password Double-Check (eliminates end-users simply adding digits to the end of bad passwords)

After doing this, organizations can be confident that their employees are choosing strong passwords. Yes, users will need to update their password in 180 days or 1 year, but this is not very inconvenient and when they do, their password choice is scrutinized against blacklists again (to catch any passwords that have since been added to the blacklists).

Now, these organizations have an easy to understand password policy with a good length requirement (10+ characters), easy to meet complexity requirements, and they know that all the passwords in their Active Directory have already been scrutinized against up to 3 blacklists.  Therefore, even if the business is hit by a credential stuffing/password spray attack, which will probably happen, it will not be successful.

The post Password Policy Recommendations for 2020 appeared first on Password RBL.

When a user picks a password, it gets checked against the Active Directory password policy. If it meets the policy, then Password Firewall checks to make sure it isn’t blacklisted. If the blacklist query comes back negative (the password is not on any blacklists) then the password is allowed. This is normal behavior.

But if you enable DoubleCheck, before allowing the password choice, another check is performed. Password Firewall will drop any digit characters (0-9) from the end-user’s password choice. Then the “new” password is queried against blacklists.  If the blacklist query comes back negative this time, the password is allowed. If the blacklist query comes back positive, then we have an end-user who is choosing a known bad password, but simply adding a number or two at the end. This isn’t very secure, so Password Firewall (with DoubleCheck enabled) will make the end-user pick a new password.

Password DoubleCheck Works for Custom Blacklists and Pwned Passwords, too!

Since this process is all client-side, the DoubleCheck process works for all blacklists you are configured to query. This includes the Password RBL curated blacklist, Pwned Passwords and your own custom blacklist.

DoubleCheck makes using Custom Blacklists easier.

Enabling DoubleCheck definitely increases your security, but it also makes populating Custom Blacklists easier. Once we enable DoubleCheck, we know Password Firewall will catch any blacklisted permutations, even if they have a string of numbers at the end. So, this means that you do not need fill your custom blacklist with any permutations that end in digits! This makes generating the permutations and adding them to your custom blacklist faster and easier! Now that’s a win-win.

The post Feature Post: Password DoubleCheck appeared first on Password RBL.

1.  We do not have the correct Public IP addresses authorized for you.  You need to inform Password RBL of the Public IP address(es) associated with any business sites where Password Firewall is running. The easiest way to do this, is to open a web browser on each domain controller and browse to: https://www.whatismypublicip.com/

2.  The other issue that can prevent Password Firewall from reaching our API is a company webfilter or proxy that is preventing access to “api.passwordrbl.com”.  This is the only URL that is needed by Password Firewall, so most customers choose to exempt this URL from their Proxy requirements, or whitelist it in their webfiltering solution.

(NOTE: By default, Password Firewall will continue to allow password changes to occur when there is a connectivity problem, so you are not impacting your users).

The post FAQ: Why am I receiving Error EventID 3401 “Failed to connect to API” appeared first on Password RBL.

Yes, using a Azure AD Connect feature called “Password Writeback.”

The Longer Answer

The Microsoft Azure AD Connect sync tool supports a feature called Password Writeback that requires password changes made in the cloud to be evaluated against your on-premise Active Directory.  Password Firewall for Windows operates as an extension to the built-in password policy engine in Windows. This means that whenever a password is changed in the cloud (or on-premise), Password Firewall will scrutinize the password choice against all configured blacklists, including your own custom blacklist if you use that feature.

The Password Writeback operation happens in real-time, so if a blacklisted password is chosen, the user receives a standard message prompt in the cloud portal reporting that their password choice did not meet the organization’s password policy.  If the end-user wishes to change their password, then they are required to make a new password choice.

You can read about the Password Writeback feature here:
https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-writeback

The Final Answer

Password Firewall for Windows prevents use of bad passwords and is a great way to protect your Office 365-enabled organization.

The post FAQ: Is Password Firewall Compatible with Office 365? appeared first on Password RBL.

Yes

The Longer Answer

Customers of Okta’s Identity and Access Management (IAM) platform that also have an on-premise Active Directory link the two directories using Okta’s DC Agent, which employs a technology Okta dubs Delegated Authentication. This means that when a user authenticates to Okta, either at their web portal or via a Federated authentication connection, the username and password they supply is not verified against the Okta directory. Instead, Okta takes the supplied username and password and immediately checks them against the on-premise Active Directory via the DC Agent connection registered in the Okta tenant. This means that there actually is not a permanently stored (and synchronized) password at Okta.  But rather, Okta temporarily remembers the password that the end-user supplied during the login process (after the on-premise Active Directory confirms the values are correct).  Then, Okta applications can utilize this remembered password in future third-party application authentications.

A similar process occurs when an Okta user changes their password. Since there is no permanently stored password for the end-user in Okta, the newly chosen password is pushed down to the on-premise active directory for storage. But, the new password must meet the on-premise active directory password policy in order for the password change to be successful. Since Password Firewall operates as an extension to the normal Active Directory password policy, any Password Firewall checks must also be successful.

So, this means that when end-users update their password in the Okta portal, those passwords are still scrutinized by Password Firewall. And this is a good thing, because Okta becomes the central authentication hub of all cloud services for companies. Successful logins to Okta provide significant access to other third-party applications. This means that passwords in use at Okta need to be strong and definitely not passwords that have already been leaked in a public data breach.

The Final Answer

Password Firewall for Windows prevents use of bad passwords and is a great way to protect your Okta-enabled end-users.

The post FAQ: Is Password Firewall Compatible with Okta? appeared first on Password RBL.