Passwords should be matched against a "password blacklist"

[eabili0]

We should match the provided passwords on registration/update against a "password blacklist".

We should check against "haveibeenpwned" without degrading the user experience. If it takes to long to respond or it breaks, we need to check the password against an in-house "black list".

The mechanism of how to construct and evolve this in-house blacklist is open for discussion.

[erickmoreno]

The haveibeenpwned API have many advantages over an in-house solution.

• It is naturally dynamic and automatically updated
• We can search for compromised passwords AND accounts

But, to keep a minimal validation, a local list to verify the proposed password against the 1000 more used can be a good plan B.

[eabili0]

The haveibeenpwned API have many advantages over an in-house solution.

We are definitely not looking for a in-house solution that matches all the features haveibeenpwned provides.

But, to keep a minimal validation, a local list to verify the proposed password against the 1000 more used can be a good plan B.

Any suggestions of how would that list be created/maintained? Should we just cache the responses we get from haveibeenpwned? Should we just maintain a static list (build time) that gets updated not very often? Or maybe should we create a database table with proper admin apis to update those records?

Maybe you have another strategy not listed above? Thanks!

[erickmoreno]

My suggestion is download the haveibeenpwned passwords list that is already ordered by prevalence and choose a feasible number of the first positions to keep with us.

To choose the number of passwords kept in-house we could consider the maximum number that keeps the file size and search time manageable under our structure.

[claudiosegala]

@abilioesteves should we proceed with @erickmoreno ideas of retrieving from haveibeenpwned? Should I implement something to update the file from time to time? Or just from command? Or simply let that for the developers?

[eabili0]

Not a priority at the monent, @claudiosegala. Thanks!