End User Security: Account Takeover Protections with Cloudflare

End user account security is always a top priority, but a hard problem to solve. To make matters worse, authenticating users is hard. With datasets of breached credentials becoming commonplace, and more advanced bots crawling the web attempting credential stuffing attacks, protecting and monitoring authentication endpoints becomes a challenge for security focused teams. On top of this, many authentication endpoints still rely just on providing a correct username and password making undetected credential stuffing lead to account takeover by malicious actors.

Many features of the Cloudflare platform can help with implementing account takeover protections. In this post we will go over several examples as well as announce a number of new features. These include:

• Open Proxy managed list (NEW): ensure authentication attempts to your app are not coming from proxy services;

• Super Bot Fight Mode (NEW): keep automated traffic away from your authentication endpoints;

• Exposed Credential Checks (NEW): get a warning whenever a user is logging in with compromised credentials. This can be used to initiate a two factor authentication flow or password reset;

• Cloudflare Access: add an additional authentication layer by easily integrating with third party OATH services, soon with optional enforcement of managed devices (NEW);

• Rate Limiting on failed logins: stop brute force credential stuffing attempts to your application;

When used in conjunction, these features can be a powerful and easy tool to deploy to increase end user account security.

In July 2020 we introduced IP lists - a reusable list of IPs users can create and maintain as a primitive when writing custom Firewall Rules. Although this is a great tool for any Firewall administrator, like any IP list used for access control - it quickly becomes outdated.

With our new Cloudflare Open Proxy Managed list - you can now write custom firewall rules and match against a list that is fully managed and regularly updated (every hour) by Cloudflare. The list is populated based on observed network traffic and proactive searching of open proxy endpoints.

The new Open Proxies managed list - can be found under Account Home → Configurations → Lists or used directly in a custom rule

By combining the IP list with additional filters when writing custom Firewall Rules, you can decrease the risk of malicious login attempts to your authentication endpoints. Writing a rule leveraging the new list, using our wirefilter syntax, would look like:

http.request.uri.path contains "/login" and (not ip.src in $cf.open_proxies and cf.bot_management.score < 30)

Any authentication attempt will then be BLOCKed or CHALLENGEed according to the chosen action on the rule.

The SOCKs and Proxy IP list is available for all Enterprise customers.

Login endpoints present an opportunity for bots. And bad bots make really good use of time by testing thousands, if not millions, of credentials in just a few seconds. These bots will persist until they have extracted some kind of value from your site.

Fortunately, we recently released Super Bot Fight Mode. This feature is included in all Pro and Business plans, and we’ve paired it with real-time analytics so you can watch attacks as they happen. Super Bot Fight Mode was built to stop credential stuffing. Under the hood, we’re running many of the same detection engines that power our Enterprise Bot Management product.

Our new Super Bot Fight Mode. Can be found under Firewall → Bots

The best part: you can add protection immediately. Pro users can choose to allow, block, or challenge “definite bots” on the Internet. Business users can even target “likely bots,” which tend to be more sophisticated and difficult to spot. Our Free users can continue to use the Bot Fight Mode toggle for basic protection.

Credential stuffing attackers try to login to a target account with a username/password pair - a user’s credential - that was previously stolen in a breach of some other service. This works sadly often because more than 50% of users reuse the same password for multiple accounts - and the result is a large number of breached accounts. Your own end user account security therefore relies not only on the security of your own systems, but on the security of all other systems used by your users. And while multi-factor authentication can provide defense-in-depth, many authentication services and users don’t yet employ it and, even so, we’d like to be able to warn services and their users when a username/password pair is vulnerable.

In addition to other approaches like bot detection, a new best practice in industry is for login services to themselves check if one of their user’s credentials is in a known data breach. This requires having a good set of known breached username/password pairs. Services like Have I Been Pwned and Google’s Password Breach Alerting aggregate large databases of known-breached username/password pairs, and allow companies or end users to do a lookup to determine vulnerability. But integration can be challenging, and ideally organizations would be able to turn on credential checking protection with the push of a button.

We’re doing just that. Today, we’re launching a new feature of the Web Application Firewall (WAF): Exposed Credential Checks.

Exposed Credential Checks can be easily enabled with our Managed Ruleset. Alternatively, you can write your own custom rules.‌‌

Login requests for any application protected by Cloudflare are routed through the WAF, and this provides the opportunity for an “on-path” exposed credential check. When enabled, on any authentication attempt, the WAF will automatically check end user credentials against a database of leaked credentials gathered and maintained by Cloudflare. In the event that a match is found, the WAF will add a header to the origin, so that your application can be warned about a vulnerable credential and, for example, trigger a password reset flow for that user or a second factor authentication challenge.

Handling usernames and passwords is, to say the least, highly sensitive and we’ve architected the exposed credential check feature to protect user credentials. A key design principle was that the username/password pair should never be exposed outside the boundaries of the WAF process, thereby ensuring we can perform the check without adding any additional risk. That means the feature never transmits usernames or passwords outside the WAF process or logs them¹ as we have no interest in knowing what any of these credentials are -- only if they pose a risk to the security of your network. But even beyond that we have built a privacy-preserving cryptographic protocol to perform the database look-up. Roughly speaking, we apply a keyed cryptographic hash function to the username/password pair within the WAF process and check whether the resulting hash value matches keyed hashes of pairs from our database of known breached credentials. We will explain this further in a follow up technical deep dive.

Starting today, Enterprise customers can request access to this feature by contacting our team on this page. Exposed credential checks are provided both as a managed ruleset, that will work “out of the box” for common systems such as WordPress, Joomla and others, and as a filter for custom rules so that any application can be supported.

With Cloudflare Access you can provide an additional authentication layer in front of any application protected by Cloudflare. Access protects applications by verifying user identity, location and network on every request. This naturally increases security for the end user account.

The device the user is using may, however, still not be secure. A valid authentication session with a compromised device may lead to data exfiltration, or worse, total compromise of the end user account or application. Enterprises try to reduce this risk by managing and issuing corporate devices where security policies can be enforced via mobile device management (MDM) solutions.

To solve this problem, we are improving Cloudflare Access to enforce that only corporate devices access sensitive applications. Via access rules, it is now possible to verify a device’s serial number against a list of managed devices before allowing access. Even if a user’s credentials were to be exposed, any unauthorized access would be blocked due the device having a serial number outside the list of managed devices. For more information see our recent announcement.

Brute force attacks are surprisingly effective, especially when performed by iterating over databases of leaked credentials. To stop these attacks, it is often sufficient to slow them down to the point they are too expensive to execute.

On a failed login attempt, many username/password forms will issue a HTTP 403 Forbidden status code or other recognisable error message². This can be used as a very effective signal to issue a rate limit response, hence avoiding any potential side effect to legitimate users.

The rule above rate limits any IP after 5 consecutive failed login attempts in a minute for 1 hour.

The rate limiting response can be customised as necessary to support both APIs with JSON payloads or standard HTML based endpoints.

Rate limiting is available to all self service customers as a paid add on.

We are spending a lot of time thinking about how to best secure end user accounts with easy one click solutions.

By leveraging our network visibility we are starting to gain valuable insights that only come with the Cloudflare scale. Our managed open proxy list is one such example but we are already experimenting with anomaly based detections going far beyond simple device posture or rate limits. Additionally we are thinking through use cases and scenarios on how to share verified anomalies more broadly across our entire customer base, bringing us back to the original community protection based approach Cloudflare was built upon.

..... ¹Other Cloudflare features, such as Encrypted WAF Payload Logging, may log any request component, but it will be encrypted with a customer provided public key

²Many penetration testing reports will highlight any difference in response to a failed login attempt as an information disclosure vulnerability.