Breached password detection
What is breached password detection?
Breached Password Detection is a security control built into LuxID that prevents users from setting passwords known to have appeared in public data breaches.
It runs automatically at two moments in the account lifecycle:
- Account registration - when a user sets their initial password
- Password reset - when a user creates a new password via the reset flow at https://login.luxid.lu/auth/reset (opens in a new tab)
If the password the user has chosen matches a known breached credential, LuxID blocks the attempt and prompts the user to choose a different password. The account is not created (or the reset is not completed) until a non-breached password is provided.
Why use it?
Credential stuffing is one of the most common and effective attacks against consumer identity systems. Attackers obtain lists of username/password pairs from historical breaches and replay them at scale against other services. Users who reuse passwords across accounts are particularly vulnerable.
By blocking breached passwords at the point of entry, LuxID reduces the credential-stuffing attack surface for every LuxID Partner without any integration work on the Partner's part. A password that has appeared in a public breach is, by definition, no longer a secret - blocking it protects the user even if they are unaware of the breach.
This control is especially important given that LuxID is used across multiple applications (RTL Play, MyPost, CFL services, and others). A compromised LuxID credential could grant an attacker access to all of a user's connected applications simultaneously.
How it works
LuxID uses a k-anonymity technique to check passwords against breach intelligence without ever transmitting the raw password or even a full password hash outside LuxID's infrastructure. The process is:
- LuxID computes the SHA-1 hash of the candidate password on the server side.
- Only the first five characters of the hex-encoded hash are sent to the breach intelligence source as a query prefix.
- The intelligence source returns all hashes in its database that begin with those five characters (typically hundreds of entries).
- LuxID checks whether the full hash of the candidate password appears in the returned list.
- If a match is found, the password is rejected and the user is prompted to choose another.
- The raw password and the full hash never leave LuxID's infrastructure.
This design means that even if the network call to the intelligence source were intercepted, an attacker would learn only a five-character hash prefix - insufficient to reconstruct the password or identify which specific password was checked.
Developer impact
No integration required
Breached Password Detection is enforced by default for all LuxID Applications. Partners do not need to implement, configure, or call any API to benefit from this protection. It operates entirely within the Universal Login flows at https://login.luxid.lu (opens in a new tab).
No error code surfaced to the Partner
When a breach is detected, LuxID presents an inline error message to the user on the Universal Login page and prompts them to choose a different password. The authorisation flow does not complete, so no authorisation code or token is issued. Your application does not receive a specific error code indicating a breached password was detected - from your application's perspective, the user simply has not completed authentication yet.
This is by design: surfacing a breach-detection error code to the Partner application would reveal information about the user's password choices that the Partner has no need to know.
Event: user.password.breach_detected
This event is part of the planned Event Hub catalogue. Today the Event Hub emits only ClaimValuesChanged (pull delivery); user.password.breach_detected is not emitted yet. See Events and Event Hub for the current state, and confirm availability with LuxID before building against it.
When emitted, a user.password.breach_detected event will be raised on the Event Hub when a breached password attempt is detected. Partners subscribing to user security events would be able to use it for:
- Security monitoring and alerting (forwarding to a SIEM)
- Identifying users who may be at elevated risk due to password reuse habits
- Internal audit and compliance reporting
The event carries the Application-scoped sub identifier, the timestamp, and context about the detection. It does not carry the password or any hash of the password.
See Events and Event Hub for the full event catalogue and webhook setup.
Sample event payload
{
"event_type": "user.password.breach_detected",
"event_id": "evt_7f3a1c2d-8b4e-4f2a-9c1d-3e7b9a2f1c4d",
"occurred_at": "2026-05-22T09:14:32Z",
"application": {
"id": "app_rtlplay_prod",
"name": "RTL Play"
},
"subject": {
"sub": "a3f2c1d8-9b4e-4a2f-8c1d-3e7b9a2f1c4d",
"email": "utilisateur@example.lu"
},
"context": {
"trigger": "password_reset",
"ip_address": "192.0.2.45",
"user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)"
}
}
The trigger field indicates whether detection occurred during registration or password_reset.
Configuration
Breached Password Detection is enforced by default for all LuxID Applications and is not Partner-configurable. It cannot be disabled at the Partner or Application level.
This is an intentional policy decision: the protection is only effective if universally applied. Allowing Partners to opt out would create a two-tier security posture within the LuxID ecosystem, which would undermine user trust.
There is no configuration surface for this feature with LuxID.
User experience
When a user enters a breached password during registration or reset, they see an inline error message on the Universal Login page explaining that the chosen password has appeared in a known data breach and inviting them to choose a different one. LuxID does not tell the user which breach the password appeared in or how many times it has been seen.
The user may try a different password immediately; there is no lockout or cooldown triggered by a breach detection event. Only actual failed authentication attempts (wrong current password, wrong OTP, etc.) contribute to lockout counters.
User-facing messaging is managed by LuxID and is available in English, French, German, and Luxembourgish.
Security and privacy notes
No password transmission. The raw password never leaves LuxID's server-side processing. The k-anonymity prefix technique ensures that even the breach intelligence source does not learn which specific password was checked.
No storage of rejected passwords. LuxID does not log or store rejected passwords or their hashes. The check is stateless: compute, query, compare, discard.
Event privacy. The user.password.breach_detected event carries the Application-scoped sub, not a cross-Sphere identifier. A Partner receiving this event cannot correlate it with the same user's activity in another application.
GDPR basis. The breach detection check is performed as part of LuxID's legitimate interest in maintaining platform security (GDPR Article 6(1)(f)). No personal data is shared with the breach intelligence source: only a five-character hash prefix is transmitted, which cannot be used to identify a person or reconstruct a password.
Does not replace MFA. Breached Password Detection reduces the risk of credential stuffing but does not eliminate it. Passwords not yet appearing in a public breach may still be weak or reused. MFA remains the most effective additional control. See Multi-factor authentication.