Over the last fifteen years databases of hundreds of services have leaked: forums, shops, social networks, gaming sites. Almost any address older than a couple of years shows up in at least one breach. So what matters is not the fact itself but the details: what leaked, when and from where.
What to look at
- Which fields were exposed. Email and username are nearly harmless. A password or its hash, phone, address or date of birth is serious.
- When it happened. A password from a decade-old breach has most likely been changed. A fresh breach is a reason to act today.
- Where from. A breach of a site where the person kept work data is worse than one of a forgotten forum.
How Oracul checks
The check uses the public XposedOrNot breach database: for an email Oracul gets the list of breaches, their dates and the types of exposed data. Passwords and database contents are never requested or stored. The check is available on paid plans.
If the exposed fields include passwords, the scan signals carry the breached_credentials flag, next to the breach count so you can set your own thresholds.
A breach as an antifraud signal
In antifraud a breach cuts both ways. An address with several old breaches is indirect evidence that it is real and has been used for years: a synthetic address created for one application has nothing to leak. A fresh breach with passwords points to account takeover risk: a login from a new device with such an address deserves a stricter check.
A breach as a security task
- Check whether the leaked password is reused in corporate systems.
- Force a change and turn on a second factor.
- Warn the employee: phishing in the name of the breached service is likely.