Password security, Banlist Upgrade about notification-api

While maybe 8 character passwords is a little small, it can be good enough if paired with other rules. To guess a truly random 8 character password assuming one thousand guesses per second would take around 2.13 thousand centuries. But if you could guess those passwords at a rate higher than one hundred billion guesses per second it would take less than 18.62 hours. This is all copy and pasted from the math over at https://www.grc.com/haystack.htm. /

There is an upgrade available in this space however that we could contribute back upstream.

The "blacklist" should be broken out into two. Blacklist one should be smaller and contain more context-specific words, such as the name of the service, the username, the name of the organization using it, and derivatives thereof, etc..

While Blacklist two should search an another larger archive of already breached passwords and make suggestions back to the user if that password choice is poor. https://haveibeenpwned.com/API/v2#PwnedPasswords

A lot of good validator ideas for memorized secrets can be found here: https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret

The importance of good secrets becomes less important when the users second factor is a security key that support Universal 2nd Factor https://developers.yubico.com/U2F/. Which is a space I believe we should also contribute to.

[willeybryan]

So adding a blacklist of words for passwords sounds like a good and easy fix. (Depending on how the system is set up)

Yubikeys sounds amazing but I am not ready to commit to that yet. Lets see how Alpha goes, and if this gets adoption then we can use it as a platform to push the Yubiagenda.

What do we need to implement the black list. I figure we need to make our own, plus we can use the poor password choice. Then is it just a matter of integrating it into account creation and the password changing screen?

In the codebase there already is a blacklist of passwords available here. But there are better practices to follow these days. For example instead of the roughly 6900 passwords available in the code, we can instead use the have I been pwned list of half a billion. This aligns with the NIST 800-63 recommendations on how to handle memorized secrets.

The second blacklist (or however we go about it) would be slightly more dynamic and make sure the users passwords aren't the name of their department, their username, or anything else associated with them in the database.

As for the security key implementation. I'll do some research on the side as I'd like to see the elimination of phishing and account take over threats if this product heads towards real use.

I'm going to attempt the banlist upgrade some sprint soon.

[maxneuvians]

Super easy wrapper on the API https://pypi.org/project/pwnedpasswords/

[willeybryan]

In done column so I am going to close