Consider validating password integrity with k-anonymity

[jeffbryner]

https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/

is an interesting development that makes it possible to check for password breach without disclosing the password to a third party. Since the NLX accepts password entries, it could be the first one to notify a user that their password is vulnerable due to disclosure in a breach.

[gene1wood]

Would this be better to do at login.mozilla.com at the point when the user is setting their password? This would be the point where the user would have agency over what their password was.

Then potentially once it was in place we could do a one time pass where we compare all our hashes to the HIBP dataset and contact users that their current address is weak.

Also, to side step the whole k-anonymity question we could pretty easily just host the dataset ourselves and call it locally.

[jeffbryner]

True, but if a new breach happens after setting up an account via 'login' the user would be unaware vs finding out via a session expiration.

[gdestuynder]

we can implement it in a few different ways: 1 - any haveibeenpwn style result gets detected by something like mozdef (or a lambda func.) and an alert is issued to the user (regardless of pw hash) 2 - auth0 rules call kanonymity and block login or issue an alert (note: block login is dangerous as well) 3 - ldap runs kanonymity in the background and does the same as 1

due to how these mechanisms work I suspect 1) is safer as so not to block users from login in by mistake. also, ideally, we'd score profiles. eg:

• login from new location
• user agent changes
• listed on haveibeenpwn
• positive signal from kanonymity
• tigerblood reports IP as bad
• etc

each could add weight + alert, but if score > x also block login + alert internally until score < x

Note: none of these are in NLX, I suspect it'd be more of a generic IAM capability for fraud detection

[jeffbryner]

Good point. I agree it shouldn't block login, but should generate something to followup on, and doesn't need to be in NLX.

[hidde]

@jeffbryner Can I close this issue here / is there a new one in a more general IAM repo?

[jeffbryner]

If you don't think it's a NLX, UI issue sure.

[hidde]

I think this would be great to have as part of a sign up flow and possibly as part of a mechanism that triggers SSO Dashboard security alerts ( +@andrew).

For now I would prefer it not to be part of NLX UI as we want people to be on NLX as short as possible, so the fewer calls/checks the better.

[gdestuynder]

@hidde did you copy this somewhere else? (mozilla-iam/mozilla-iam if no other place comes to mind)

[hidde]

@gdestuynder I've just opened this in mozilla-iam/mozilla-iam: https://github.com/mozilla-iam/mozilla-iam/issues/44