Password Reset Portal: Can't "delete all" from Bad Passwords list

[markeldo]

I've been trying to configure our Password Reset Portal with the "Bad Passwords" feature, by uploading the top 100,000 most common passwords from the seclists repository: https://raw.githubusercontent.com/danielmiessler/SecLists/master/Passwords/Common-Credentials/10-million-password-list-top-1000000.txt

 

Unfortunately, the upload seemed to fail partway through, and I'm left with only a portion of the passwords loaded in the "Bad Passwords" list. Unless I'm missing something obvious, there doesn't seem to be any way to delete the list and retry the upload other than clicking delete on each entry.

[support]

Hi Mark,

 

Can you please run the following SQL statement below using SQL Server Management Studio, as this will clear the list for you.

 

USE Passwordstate

DELETE FROM [PR_BadPasswords]

 

I tried copying this List to excel, and Excel even timeout out for over a minute before it was responsive. I'm not sure if there's a great deal we can do around performance for this, except I would recommend using our Password Policies instead - you can enforce the use on strong passwords, which would negate the requirement to check these "simple" passwords in the list.

Regards

Click Studios

[markeldo]

Thanks, we'll try deleting the list manually. Unfortunately I don't have direct SQL access to the database, so I'll have to wait until one of our DBAs can take a look at it.

 

As for Password Policies, unfortunately this won't help for our purposes. For example, there's no password policy I can set where "Password123!" or "Winter2018!" is not a valid password, without also blacklisting a lot of otherwise good passwords.

 

We're trying to meet the GCHQ and NIST recommendations for password management, which now recommends filtering using known-bad passwords rather than complexity requirements. This is also the reason Troy Hunt created the Pwned Passwords tool, but we can't directly use that list because the wordlists are extremely large (500m+ records) and in any case are SHA-1 hashed so we'd need additional logic in the Bad Passwords check within Passwordstate.

[support]

Thanks Mark - we understand.

 

We'd have to say though, with a list of 500m+ bad passwords, you might be there for a while trying to specify a password which is allowed

 

Regards

Click Studios

[markeldo]

It's not quite that bad. If users use passphrases (for memorisation) or randomly generated passwords, they won't have any collisions. In my experience it's far more common to run into problems with password complexity rules than with a blacklist comprised of public breaches, even if the blacklist is very large.

 

The Pwned Passwords API also provides the number of times the given password has appeared in public data breaches, which can also be useful. This way, we don't need to just prohibit the password entirely, we can notify the user that it's a poor password because "it has been used by 20,000 other people", similar to how we can already set password policies as not-enforced.

[support]

Sure, thanks Mark - that makes sense.

 

Regards

Click Studios