U4-11022 - Feature request: Add Pwned Password lookup ability out of the box

Created by Kevin Giszewski 27 Feb 2018, 16:07:03 Updated by Kevin Giszewski 18 Jul 2018, 22:49:10

Troy Hunt has created the Pwned Password service/API and it would be great to be able to optionally enable this for any user and/or member created.

Plenty of discussion on the interwebs about it.

https://haveibeenpwned.com/Passwords

User story:

  1. User account creation is started
  2. Password complexity check can optionally include a rule to check against Pwned Password API
  3. Upon success, allow creation

(Repeat for change password)

Member story:

  1. Member account creation is started
  2. Password complexity check can optionally include a rule to check against Pwned Password API

(Repeat for change password)

Only applies to the native member/user providers.

All bets are off for external auth (i.e. must be handled by developer).

Would be nice to have a service that is re-usable for this baked-in for public use.

Comments

Kevin Giszewski 27 Feb 2018, 16:20:54

If this is too proprietary (which it might be), perhaps a hook into a password complexity pipeline would suffice.


Nik 27 Feb 2018, 20:01:17

A first stage implementation could just a clientside check using Javascript that when a primary password field is left it makes the call and just flags a warning saying this is a risky password if it's one of the popular ones?


Kevin Giszewski 27 Feb 2018, 20:27:34

@nik You'd need to include a client side hashing lib too as the API only takes the first 5 characters of a SHA-1 hash. Curious at what point you'd check the password. When clicking the 'create user' and 'change password' button? i.e. what's the UI do specifically?

Also this will circumvent the Umbraco API's which I would want to be the ultimate enforcer (membership provider, etc).

Just providing feedback, not dismissing your suggestion ;)

Possible solutions in no particular order:

  1. Client-side checks
  2. Bake it into the membership logic server-side with a toggle to enable/disable
  3. Provide observable events that would allow custom code to hook into a 'OnPasswordChanging' event and be able to reject password (least coupled to an implementation)
  4. Provide a pipeline instead of observable and any number of password rules can be adopted
  5. Other

The more I think about it, option 3 or 4 are least intrusive and allows for any flavor of implementation to be chosen. The rest are more coupled.

Just my humble opinion.


Matt Cheale 13 Mar 2018, 09:50:31

3 and 4 are good options for Umbraco but I would want to have a way of notifying the user before they submit the form. Perhaps the user password validation could hook into this in some way?


Kevin Giszewski 18 Jul 2018, 22:49:10

Having seen this tweet generate a possible prototype, maybe now is a good time to add a feature request: https://twitter.com/callumbwhyte/status/1019682156598235137

Since the API incurs a dependency, I'd like to see it gracefully fallback in case of API unavailable :)


Priority: Normal

Type: Feature (request)

State: Submitted

Assignee:

Difficulty: Normal

Category: Security

Backwards Compatible: True

Fix Submitted:

Affected versions:

Due in version:

Sprint:

Story Points:

Cycle: