Jump to content

Improve Bad Passwords feature


nickl

Recommended Posts


Hi,

Given the recent publishing of new NIST guidelines, https://www.nist.gov/itl/tig/special-publication-800-63-3,  and the Have I Been Pwned database of hacked passwords, https://haveibeenpwned.com/Passwords, just wondering if there are any plans to improve the "Bad Password" feature in Passwordstate?

 

I imagine importing 300M records into the Passwordstate database is a no-go, but thought I'd ask in case the developers can think of any clever ways to integrate this type of check into the product.

It would certainly be a feature I'd like to offer my staff.

 

Cheers!

Link to comment
Share on other sites

Hi Nick,

 

You're correct in that adding in anywhere near this amount of Bad Passwords would cause massive performance issues every time we needed to check this volume of records.

I'm not sure if there's really anything we could do about this, and will probably let customers decide what additional bad passwords they would need to add in themselves. Unless the community has a better suggestion for how we could do this, without impacting on performance.

Regards

Click Studios

Link to comment
Share on other sites

I figured performance would be the issue. Obviously in the case of HIBP, he's using Azure Tables for the database which scales out in ways most of us couldn't do on-prem. Not sure if anyone has any brilliant suggestions but it would be a fantastic feature to offer in a password manager.

Link to comment
Share on other sites

1 hour ago, nickl said:

Not sure if anyone has any brilliant suggestions but it would be a fantastic feature to offer in a password manager.

ClickStudios could use a noSQL database just for bad passwords. That's largely what gives Azure Tables its performance.

Link to comment
Share on other sites

Hi Guys,

 

With the current design, the database of choice is not really the issue here. We have a Regex partial matching feature for Bad Passwords, which means every keystroke performs a check to see if the password is 'Bad'. Because of this option, we hold the BadPassword data in memory on the Add/Edit screens, for performance reasons. Having 300M records in memory is not an option, as this would be X times 300M records, dependant on how many concurrent users there are logged in.

 

So if we were to explore this, we would probably need to drop the Regex pattern matching, and then make one call to the database when you hit the 'Save' button. This also means we could not show on the screen whether the password is bad or not, only at the time of hitting the Save button.

Regards

Click Studios

Link to comment
Share on other sites

Understood. A different approach would be something like how Facebook does it - they let you save the password but then at some indeterminate date in the future they alert you that your password is bad. In the case of Passwordstate that could be a scheduled task, or similar? So treat it more as a learning exercise for users rather than block them entirely.

 

Since the user's password would be hashed, I don't know if comparing hashes is safe or even feasible in this circumstance.

Link to comment
Share on other sites

Hi Nick,


Yes, this could be one option, which we did consider. But we're not sure if customers would allow this, as it would allow there users to use bad passwords. Plus if we were performing password resets on AD account, windows machines, databases, etc, they may dislike it even more.

 

We do appreciate the dialog though. Also, those initial links you posted cannot be found - are there any updated ones?

Regards

Click Studios

Link to comment
Share on other sites

Thanks Nick :) I'd expect we'd be able to get reasonable performance as well if we only performed the check on clicking the 'Save' button, but we'd need to think about whether we want to make this change.

 

We've had some customer's who's SQL Server times out trying to insert 10,000 records for our WordDictionary table - I wonder how it will go inserting 300 million records, with 5 GB of data :)

Link to comment
Share on other sites

  • 9 months later...

Thanks Jeremy.

 

We would need to consider everywhere Bad Passwords are used, and consider what we do in this situation i.e. do we only worry about this in the UI, or the API as well - our concern again is performance making calls over the internet. We've done a pilot of the code for this, but have finalised how it can be implemented yet.

Regards

Click Studios

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...