Credential Reuse

Credential Reuse detects when an employee enters a tracked password on a site that shouldn't have it. The Keep Aware extension evaluates each credential entry inside the browser before the form submits, then logs the event, pauses submission, or blocks the form based on your policy.

Requirements

• Access to your Keep Aware console
• Keep Aware extension deployed to the Profiles you plan to assign the policy to
• Permission to create or edit policies in your tenant

Getting started

Credential Reuse is configured as a control inside a Browser Control policy. Before you create the policy, decide which hostnames belong on the inclusion list (typically your SSO portal and any high-value internal sign-in pages) and which action you want when reuse is detected.

Then create the policy:

1. Navigate to Policies in the console.
2. Click Create policy and set the category to Browser Control.
3. Enable Credential reuse in the controls section.
4. Add hostnames to the Inclusion list.
5. Select one or more Actions.
6. Enter a Message to show the user when Pause or Block triggers.
7. Assign the policy to one or more Profiles and save.

For broader context on browser-level controls, see Browser controls.

Why credential reuse matters

Reusing the same password across services is one of the most common ways a single phishing success or third-party breach turns into a wider compromise. Once an attacker has a working password, they often try it on every service they can find, including SSO portals, mail, and SaaS apps.

Common scenarios:

• A phishing page captures a password the user also uses for SSO.
• A breached vendor exposes a password the user also uses for corporate accounts.
• A user reuses their corporate password on a personal or unmanaged service.

Most of this risk is invisible to traditional security tooling. The reused password never crosses a network boundary that those tools can see, and there's no inbound alert until the attacker is already using the credential. Credential Reuse closes that gap by inspecting credential entry as it happens, in the browser, before the form submits.

How it works

Credential Reuse runs inside the Keep Aware browser extension. When a user enters credentials on a page, the extension evaluates whether that password matches one already associated with another site for the same user, without ever transmitting or storing the password itself.

The detection flow:

1. Local processing in the browser. At form submission, the extension reads the credential, normalizes the value, and applies a cryptographic hash mixed with per-user context so that the same password typed by two different users produces different outputs. The plaintext is discarded immediately. Nothing about the password is written to browser storage, disk, or logs.
2. Sealed transit to the backend. The hashed value is wrapped in a hybrid public-key envelope using a per-tenant public key. The matching private key lives only on the Keep Aware backend, in a secrets store separated from the application layer. A captured payload cannot be opened without that key, and a key from one tenant cannot decrypt traffic from another.
3. Server-side keyed transformation. After decryption, the backend runs a keyed one-way cryptographic transformation over the hash. The key is a server-side secret that is never sent to clients, never present in browser code, and held apart from the data it protects. The output of this step is the only credential-derived value Keep Aware retains.
4. Per-user comparison. The transformed value is matched against previously stored values for the same user within the same tenant. Neither the browser-side hash nor the in-transit payload is ever used as the comparison key — only the server-derived output is.
5. Action. If the value matches one stored from a different hostname or username, the policy's configured action runs.

This separation of stages is the core of the design. A breach of the browser yields no stored credentials. A breach of the transport yields ciphertext bound to a tenant key the attacker doesn't have. A breach of the storage system yields values that cannot be reversed or guessed offline without the server-side secret, which is held elsewhere.

Inclusion list

The inclusion list is the set of hostnames Keep Aware is allowed to learn credentials from. It defines the boundary between “this is a password being tracked” and “this is a password being checked”.

• Credentials submitted on a hostname in the inclusion list are added to the user's tracked set.
• Credentials submitted anywhere else are checked against that set but never added to it.
• Each user's tracked set is scoped to their browser identity within your tenant.

For example, if okta.certaincyber.com is in the inclusion list, that user's password is learned the first time they sign in there. If the same user later types that password on certaincyber-okta.com, the policy triggers.

Trust and data handling

Credential Reuse is designed so that Keep Aware never holds anything that could be used to recover, replay, or test a user's password. The threat model assumes that any stored value could eventually be exposed, and the system is built so that exposure still produces nothing usable.

• Plaintext never leaves the browser. The password is hashed locally before any network call. Keep Aware servers, logs, and backups never see the password itself.
• The browser-side hash is bound to per-user context. Two users typing the same password do not produce the same hash, so a stolen value cannot be used to identify other users with that password.
• Encryption in transit uses per-tenant keys. The browser encrypts the hashed value to a tenant-specific public key. The matching private key lives on the Keep Aware backend in a secrets store separated from the application layer.
• Stored values are one-way and keyed. A server-side keyed transformation runs before storage, using a secret that is never sent to clients, never present in browser code, and never written into the same systems as the data it protects. The result cannot be reversed into a password.
• Stored values are not testable offline. Because the keying secret is held apart from the storage system, a copy of the database on its own cannot be brute-forced or matched against a password list.
• No raw hashes are stored. The browser-side hash is a transit format. The value written to storage is derived from it server-side and is not the same value the browser produced.
• Stored values exist only for reuse detection. They are scoped to a single user within your tenant and are not shared, exported, or used for any other purpose.

Configuration

Inclusion list

A list of hostnames Keep Aware learns credentials from. Format hostnames without protocol or path (okta.example.com, not https://okta.example.com/login).

Tips:

• Include the hostnames where employees sign in to your most sensitive accounts.
• Keep the list short. The inclusion list is about what to track, not what to allow.
• Hostnames not on this list are never learned, only compared against.

Actions

You can select any combination of actions. Each runs independently when reuse is detected.

Action	Behavior	User experience
Log	Record the event for reporting and investigation.	The user is not interrupted.
Pause	Disable form submission and display the message.	The user can edit the entry and submit again.
Block	Disable form submission and the surrounding form fields.	The user cannot retry on this attempt.

When Pause and Block both apply to the same submission, Block takes effect.

Message

A short message shown to the user when Pause or Block runs. Use it to tell the user why submission was stopped and what to do next. If multiple credential reuse policies trigger on the same submission, the first message found is shown.

Use cases

Detect SSO password reuse on third-party sites

Track the password used at your SSO portal and pause submission whenever it shows up on any other site so the user can correct course.

Category: Browser Control
Control: Credential reuse
Inclusion list: sso.company.com
Actions: Log, Pause
Message: "This looks like your corporate sign-in password. Don't use it on other sites."
Profiles: All Employees

Block corporate password reuse on consumer services

Track the corporate password and prevent submission on consumer services where users sometimes reuse it.

Category: Browser Control
Control: Credential reuse
Inclusion list: sso.company.com, mail.company.com
Actions: Log, Block
Message: "Your corporate password cannot be used on this site. Contact IT if you need help."
Profiles: All Employees

Frequently asked questions

Question	Answer
Does Keep Aware send my users' passwords to your servers?	No. Passwords are hashed in the browser before any network call. Plaintext passwords never leave the device.
Can Keep Aware recover or replay a stored password?	No. Stored values pass through a one-way keyed transformation using secrets that are not exposed to clients. The result cannot be turned back into a password.
What happens if a user gets a false positive?	Configure the policy with Pause instead of Block. The user sees the message and can correct or retry without being locked out of the form.
Does this work with password managers and autofill?	Yes. Credential Reuse evaluates the value present in the field at submission time, regardless of how it was entered.
Are credentials shared across users or tenants?	No. Tracked values are scoped to a single user within a single tenant.
Does Keep Aware track every password a user types?	No. Only credentials submitted on hostnames in the inclusion list are tracked.
Can the same password be tracked against multiple inclusion-list sites?	Yes. Each inclusion-list hostname maintains the user's password for that site. Reuse is flagged when the same password appears at a hostname or username that doesn't match where it was learned.