Detect and prevent account-related fraudulent activities on websites

This document shows you how to use Account defense to detect and prevent account-related fraudulent activities on websites.

Fraud Defense helps you protect critical actions, such as login and checkout. However, there are many subtle forms of account abuse that can be detected by observing a specific user's behavior on a website over a period of time. Account defense, a feature of Fraud Defense, helps in identifying these kinds of subtle abuse by creating a site-specific model for your website to detect a trend of suspicious behavior or a change in activity. By using the site-specific model, Account defense helps you detect the following:

  • Suspicious activities
  • Accounts with similar behaviors
  • Requests coming from devices that were marked as trusted for specific users

Based on the analysis of Account defense and the site-specific model, you can take the following actions:

  • Restrict or disable fraudulent accounts.
  • Prevent account takeover attempts.
  • Mitigate the successful account takeovers.
  • Grant access only to the requests coming from legitimate user accounts.
  • Reduce friction for users logging in from one of their trusted devices.

Before you begin

  1. Prepare your environment for Google Cloud Fraud Defense.
  2. Create a score-based site key.

Configure your web pages for Account defense

Account defense requires a comprehensive understanding of account activities to enable effective detection. To start feeding account-related activities to Account defense, and to create and improve your site-specific model, do the following:

  1. Enable collection of horizontal telemetry data.
  2. Report on critical user actions.
  3. Assess critical user events.
  4. Annotate user events to tune your site-specific model.

Enable collection of horizontal telemetry data

Account defense requires a complete view of user actions, such as whether the user is logged in or is about to log in. To enable passive collection of horizontal telemetry data by Account defense Account defense, load the reCAPTCHA JavaScript script with the score-based site key that you created in the background of all the web pages that are part of your user workflow.

The following example shows how to load the reCAPTCHA JavaScript script in a web page.

    <head>
    <script src="https://www.google.com/recaptcha/enterprise.js?render=KEY_ID"></script>
    ....
    </head>

Report on critical user actions

To detect suspicious activity patterns and build a better model of typical activity patterns on your site, Account defense needs the information about critical user actions. Therefore, report critical user actions on the web pages by calling grecaptcha.enterprise.execute() on those critical user actions.

We recommend reporting all the critical user actions because it helps in additional signal collection. For every user action that you want to report, replace the value of the action parameter of grecaptcha.enterprise.execute() with an action name that describes the user action.

The following table lists the action names that you can use when reporting the critical user actions.

Action name User initiated event or user action
LOGIN

Login to the website.
REGISTRATION Registration on the website.
SECURITY_QUESTION_CHANGE Request to change the security question.
PASSWORD_RESET Request to reset the password.
PHONE_NUMBER_UPDATE Request to update the phone number.
EMAIL_UPDATE Request to update the email address.
ACCOUNT_UPDATE Request to update account related information, such as contact details.
TRIGGER_MFA An action that triggers an MFA challenge.
REDEEM_CODE Request to redeem code.
LIST_PAYMENT_METHODS Fetch the list of payment methods.

The following example shows how to call grecaptcha.enterprise.execute() on a phone number update:

    <script>
    function onClick(e) {
      e.preventDefault();
      grecaptcha.enterprise.ready(async () => {
        const token = await grecaptcha.enterprise.execute('KEY_ID', {action: 'PHONE_NUMBER_UPDATE'});
      });
    }
    </script>

Assess critical user events

When you call grecaptcha.enterprise.execute() on a user action, it generates a token. For the critical user events, such as successful and failed logins, registrations, and actions of the logged-in users, create an assessment to assess the results of the grecaptcha.enterprise.execute() call. The assessment provides you a risk verdict, which you can use to make a decision about how to handle potentially fraudulent activities. Some of the actions you can take are blocking suspicious requests, challenging risky logins, and investigating accounts of interest.

Account defense requires you to provide a stable account identifier to make the assessment and to attribute user activity–such as login requests, logged-in requests, and signup requests–to a specific account. This helps Account defense process user activity patterns to build an activity model for each account to better detect anomalous and abusive traffic.

Choose a stable account identifier accountId that is not often changed by the user and provide it to the assessment in the projects.assessments.create method. This stable account identifier should have the same value for all the events related to the same user. You can provide the following as the account identifier:

User identifiers

If every account can be uniquely associated with a stable username, email address, or phone number, you can use it as the accountId. When you provide such cross-site identifiers (identifiers that can be reused across sites), Fraud Defense uses this information to improve protection for your user accounts based on cross-site models by flagging abusive account identifiers and using knowledge of cross-site abuse patterns related to these identifiers.

Alternatively, if you have an internal user ID uniquely associated with each account, you can provide it as the accountId.

Hashed or encrypted

If you do not have an internal user ID uniquely associated with each account, you can turn any stable identifier into an opaque, site-specific account identifier. This identifier is still needed for Fraud Defense account defender to understand user activity patterns and detect anomalous behaviour, but it is not shared across other sites.

Pick any stable account identifier and make it opaque before sending to Fraud Defense by using encryption or hashing:

  • encryption (recommended): encrypt the account identifier using a deterministic encryption method that produces a stable ciphertext. For detailed instructions, see encrypt data deterministically. When you choose symmetric encryption over hashing, you don't need to keep a mapping between your user identifiers and the corresponding opaque user identifiers. Decrypt the opaque identifiers that are returned by Fraud Defense to turn them into the user identifier.

  • hashing: we recommend hashing the account identifier using the SHA256-HMAC method with a custom salt of your choice. Because hashes are one-way only, you need to keep a mapping between the generated hashes and your user identifiers so that you can map the hashed account identifier that are returned back to the original accounts.

In addition to providing a stable account identifier for all the account-related requests, you can provide additional account identifiers, potentially non-stable, for some specific requests. Context-specific account identifiers provided in addition to the accountId help Account defense better analyze user activity and detect account takeover attempts to keep your user accounts safe. When you provide additional identifiers, Google Cloud Fraud Defense uses this information to improve protection for your user accounts based on cross-site models by flagging abusive account identifiers and using knowledge of cross-site abuse patterns related to these identifiers. For example, you can provide the following:

  • The username, email address, or phone number that was used as a login handle for login requests

  • The email address or phone number that was verified for a multi-factor authentication request

  • An email address or phone number (primary or secondary) that was provided by the user during an account update request

  • The email addresses and phone numbers that are provided by the user during a registration request

Append the chosen stable account identifier to the accountId parameter in the projects.assessments.create method for all the account-related requests. Optionally, provide additional account identifiers for the relevant requests by using the userIds field in the assessment.

Before using any of the request data, make the following replacements:

  • PROJECT_ID: your Google Cloud project ID
  • TOKEN: token returned from the grecaptcha.enterprise.execute() call
  • KEY_ID: reCAPTCHA key associated with the site
  • ACCOUNT_ID: the identifier that is uniquely associated with the user account for a user account to your website
  • EMAIL_ADDRESS: Optional. An email address that is associated with this request, if any
  • PHONE_NUMBER: Optional. A phone number that is associated with this request, if any
  • USERNAME: Optional. A username that is associated with this request, if any

HTTP method and URL: