4 ms·

Does anyone provide a regularly updated bloom filter of exposed passwords you could use for meeting the last point? Seems like something Troy could do...

• welder 9y ago
  If it's for your website, start by adding a password strength meter using zxcvbn[1]. For example: https://github.com/MorrisJobke/strengthify https://github.com/MorrisJobke/strengthify [1]: https://github.com/dropbox/zxcvbn https://github.com/dropbox/zxcvbn
• jdormit 9y ago
  Do you think the chances of false positives would make a bloom filter a bad choice for this?
  • Deimorz 9y ago
    It's not ideal, but shouldn't be a big issue, since a false positive just means that you (very rarely) tell a user that a password is unacceptable when it should have been fine. That's a bit annoying for the user, but the result is that they just end up picking a different secure password. False negatives would be worse. Really though, a list of common passwords to block is such a small amount of data that it's probably best to just use an exact list. I can't see it being more than a megabyte or so.
    • zwily 9y ago
      A "list of common passwords" isn't the guidance though - it's a list of passwords exposed in previous breaches. That list can be huge, and only practical to check with some efficient lookup mechanism.
      • Deimorz 9y ago
        Ah okay, sorry. I was thinking about it from the perspective of common passwords since that's something I've tried to find an existing bloom filter for before. I agree with you that Troy would probably be one of the best people to provide something like that. I wonder how feasible it is, that would be a really great resource to have available.
  • zwily 9y ago
    You can tune the bloom filter to have whatever false positive rate you think would be acceptable.
• TheFinalDraw 9y ago
  Hey! A thing I can actually help with! I put together a PoC of exactly this when I had the same idea a couple years ago. Here's a basic generic example I put together at the time, that also defines interfaces for other policy directives (e.g. min length, etc.): https://github.com/milo-minderbinder/policy/blob/master/src/main/java/co/insecurity/policy/directive/BFDictionaryDirective.java https://github.com/milo-minderbinder/policy/blob/master/src/... I'll add docs and updates if people give a shit. The passwords.dat file in the resources folder is the top 1m most common pws that I compiled from a number of lists available at the time. I implemented a redis-backed instance of the above common-password bloom filter in a sample Spring app which I was using to show off some features of spring security to a dev (I work in AppSec). You can see the policy and redis config here: https://github.com/milo-minderbinder/spring-ref/blob/indev/src/main/java/co/insecurity/springref/security/policy/SimplePasswordPolicy.java https://github.com/milo-minderbinder/spring-ref/blob/indev/s... And you can see an example of how to wire it up to a Spring Validator here: https://github.com/milo-minderbinder/spring-ref/blob/indev/src/main/java/co/insecurity/springref/web/domain/UserValidator.java https://github.com/milo-minderbinder/spring-ref/blob/indev/s... And you'll find where it's registered as a bean in the SecurityConfig.java file in the config dir with the other Spring java-config classes. If you want to run it, I dockerized the whole Shebang with docker-compose a whole back, which should be easy to run: https://github.com/milo-minderbinder/docker-spring-ref/tree/indev https://github.com/milo-minderbinder/docker-spring-ref/tree/... Hope any of this was meaningful to literally anyone in literally any capacity haha