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.

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.