Does Finowl ever see the full password?

Finowl receives the password over TLS, hashes it with SHA-1 and queries only a five-character prefix of the hash. The password is processed transiently and is never logged, stored or returned.

Is checking breached passwords recommended for financial apps?

Yes. NIST SP 800-63B recommends comparing new passwords against lists of values known to be compromised, which makes it a sensible baseline control for any account that holds money.

Should we reject a password that was seen only once?

Most teams reject any password with breached set to true. The count helps you explain severity or tune messaging, but even a single appearance means the value is in attacker wordlists.

Password breach checks · Fintech

Breached password checks for fintech accounts

Credential stuffing works because people reuse passwords. If a customer sets a password that already appears in breach data, attackers may try it against your login long before anyone notices. The Finowl password breach API tells you whether a password has been seen and how many times, so your signup and password-change forms can reject known-compromised choices in line with NIST SP 800-63B guidance.

For a fintech security review, the privacy model matters. Finowl hashes the password with SHA-1 and looks up only a five-character prefix of that hash using a padded k-anonymity range search. The password is processed transiently and is never logged, stored or returned, which keeps the check compatible with strict internal handling rules for authentication secrets.

Try it in the sandbox About password breaches

USE CASES

Where it fits in fintech

Signup password screening
Check the chosen password when a customer opens an account and ask for a different one if it has appeared in breaches, before the account can hold funds or link a card.
Password reset and change flows
Apply the same check whenever a customer resets or changes a password, so recovered accounts do not drift back to credentials that attackers already have in their lists.
Login-time hygiene prompts
After a successful login, optionally check the submitted password and prompt the customer to rotate it if it is compromised, without interrupting an urgent payment they came to make.
Internal back-office accounts
Screen passwords for operations and support staff who can view customer financial data, since a compromised employee credential often carries far more access than a single customer account.

HOW TO INTEGRATE

The workflow

1
Send the candidate password from your backend to POST /v1/breaches/password over TLS, never from the browser with your API key.
2
Read the breached flag and count from the response to decide whether to accept the password.
3
Return a friendly validation message that explains the password has appeared in a data breach and suggests a passphrase.
4
Avoid logging the request body anywhere in your own stack, matching how Finowl handles the password.
5
If the API returns a 5xx or times out, accept the password under your normal strength rules rather than blocking signup.

POST /v1/breaches/password

curl https://api.finowl.co/v1/breaches/password \
  -H "Authorization: Bearer $FINOWL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "password": "correct-horse-battery-staple"
}'

Returns breached and count. Finowl checks only a hashed prefix and never logs, stores or returns the password. 1 credit per check.

GOOD PRACTICE

Before you ship

Call the endpoint server side only. Exposing your API key to the browser lets anyone spend your credits and bypasses your own rate limiting and monitoring.
Keep the password out of request logs, APM traces and error reports on your side, so your own handling matches the transient processing Finowl applies.
Explain rejections clearly. A message such as this password has appeared in a known breach keeps customers moving instead of guessing at hidden complexity rules.

Read the API reference for every field and error code. Each lookup costs 1 credit; see pricing.

A FEW GOOD QUESTIONS

Common questions