Providing Required Parameters to HUMAN

For Account Defender to properly profile user activities and detect suspicious anomalies, the following parameters must be passed between the web application and the HUMAN solution.

What Parameters are Required

Unique User Account ID or User ID

Each registered and logged in user has a user ID (user_id) - a unique identifier, defined by your company. The user_id can be any string that your company uses in its system: auto-incremented number, UUID, or random characters.

Account Defender uses the user_id to:

• associate behavior profiles with a specific account to identify anomalies between the normal behavior of the account to that of an attacker
• build demographic and peer profiles and identify that a newly created account is acting differently than the population at large

User Email Address

Account Defender requires the user email address (parial or full) to verify newly created accounts. The email address associated with the account is checked against reputation databases for indications like recently registered domain, disposable email address, address associated with fraud or spam, etc.

Account Registration Date

The account registration date helps determine whether there was any activity before the deployment of the Account Defender, distinguishing between dormant and newly registered accounts. For precise data, we recommend using the ISO 8601 date and time format with UTC indication ('2023-11-01T07:35:52.000Z') or the Unix timestamp string ('1639087652'). In cases where this information is not provided, our system will automatically generate it based on the observed account registration. Alternatively, if no registration date is available, the system will assume that the first observed traffic on a specific user account represents the registration date.

How to Provide Parameters

You can provide user and account parameters to HUMAN using custom parameters:

• From the Sensor (browser activities or native mobile app/SDK)
• From the Enforcer (server activities). Custom parameters are set differently for each Enforcer. Check the Configuration Options sections under the relevant Enforcer.

Most of the parameters can be provided either from the Sensor or the Enforcer. Only the account_id must be provided from both.

Providing Parameters via Sensor

The recommended way is to set the values on HUMAN custom_param:

• window._pxParam1
• window._pxParam2
• Anywhere you save it on the page:
  Cookie (make sure the httpOnly flag is not checked)
  Local/session storage
  Window/document object

Providing Parameters via Enforcer

To provide an account ID, the Enforcer must first extract it from the HTTP Request, where it's stored in the form of a JSON Web Token (JWT) in a cookie or a header.
The Enforcer can extract the JWT fields and user_id and send it in the Risk, Page Requested and Block activities.
To enable this functionality, you need to configure the Enforcer according to your JWT implementation.

If set on a cookie, the JWT has the following configuration fields:

• px_jwt_cookie_name - the name of the cookie that contains the JWT token
• px_jwt_cookie_user_id_field_name - the name of the field that contains the user ID
• px_jwt_cookie_additional_field_names - a list of additional fields to be extracted from the JWT

If is set on a header, the JWT has the following configuration fields:

• px_jwt_header_name - the name of the header that contains the JWT token
• px_jwt_header_user_id_field_name - the name of the field that contains the user ID
• px_jwt_header_additional_field_names - a list of additional fields to be extracted from the JWT