Validating the Integration

Introduction

In order to ensure that Credential Intelligence was integrated correctly, it is recommended that the following test scenarios be executed.
The following credentials can be used in the tests mentioned below to simulate compromised credentials:

Test Scenarios

Compromised Credentials:

1. Setup a user in your system using one or more of the compromised credentials mentioned above.
2. Attempt to login using a password different from the correct one.
3. Observe that the compromised credential header (the default key for this header is px-compromised-credentials) is absent from the request going to the origin server.
4. Attempt to login using the correct password.
5. Observe that the compromised credential header exists on the request going to the origin server with a value of 1.

Non Compromised Credentials:

1. Choose an existing user or create a new one (it is recommended to use a new user when possible to lower the probability of it and it’s password existing in our database).
2. Attempt to login with an incorrect password.
3. Observe that the login failed and that the compromised credential header is absent from the request going to the origin server.
4. Attempt to login with the correct password.
5. Observe that the login failed and that the compromised credential header is absent from the request going to the origin server.

Password Reset:
In case the password reset flow has been implemented, perform the “Compromised Credentials” flow mentioned above and observe that your login is redirected to your password reset page with no option to complete the login process until the password is changed.

CIAM Integration:
In the case of a CIAM integration (e.g. Okta), depending on the integration, you might not have visibility into the request headers. In this case, or if you are ingesting this data via our data export capabilities, you will need to review the value of px-compromised-credentials flag in the data export provided.

Q&A and Troubleshooting

I am not seeing the px-compromised-credentials header on any of my origin requests, what could cause this?

If you are seeing this, please check the following:

1. That your username and request extraction configuration are properly configured.
2. That the paths configured for extraction cover the flow you are attempting to test.

If both are correct, please contact support with the full enforcer configuration and steps to reproduce the login flow and we will assist you in troubleshooting the issue.

I can’t create new users based on the credentials mentioned above, how can I still test the “Compromised Credential” flow?

In order to simulate a compromised credential response, change the User-Agent header of the original request to breached_account_pxde_test. This will force our API to return the flag identifying the request as compromised without adding it to our database or requiring you to create a new user.

I can’t see the breached account response in the logs of the data export, what could cause that?

In order to receive the breach account response in the the data export, the export should be configured via the portal by selecting data type “Logs”. Breached account response will be included by default if the feature is enabled for the app ID.
To learn more about the data export configuration, click here. To learn more about the data scheme including the breached account response, click here.