[keycloak-dev] Blacklist Password Policy
Bill Burke
bburke at redhat.com
Fri Aug 11 11:48:12 EDT 2017
Great research Thomas. Would definitely be interested in incorporating
this.
On 8/10/17 1:44 PM, Thomas Darimont wrote:
> Some more food for thought...
>
> I came up with another idea for efficiently deal with large password
> blacklists.
>
> Instead of having the plain passwords as a TreeSet (as in the current PR)
> or encoding it into something like a Radix Tree / PatriciaTrie one can also
> use a BloomFilter [0].
>
> A password blacklist would be loaded into a Bloomfilter.
> If the filter does not contain a given password then it is definitely not
> blacklisted,
> which means the user can use it.
> If the filter says it contains the value - which could be a false positive
> (with a configurable probability)
> one could tell the user to use a different password (or check the password
> list on disk just to be sure)...
>
> A Bloomfilter with 1e7 elements and a false positive rate of 1 in a million
> takes 36mb memory [1]
>
> There is Java-BloomFilter [2] - a single Java class that one can copy into
> the project if one keeps the LGPL comment in place (as stated on their
> github page).
>
> Perhaps this would be another option.
>
> I think password blacklists are another layer of security of which some say
> are superior to some
> rule based password policies - as discussed in [3]
>
> [0] https://en.wikipedia.org/wiki/Bloom_filter
> [1] https://hur.st/bloomfilter?n=10000000&p=1.0E-6
> [2] https://github.com/MagnusS/Java-BloomFilter
> [3]
> https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/
>
> Cheers,
> Thomas
>
>
> 2017-08-10 13:03 GMT+02:00 Bruno Oliveira <bruno at abstractj.org>:
>
>> In order to not miss this, I just created the following jiras:
>>
>> https://issues.jboss.org/browse/KEYCLOAK-5275
>> https://issues.jboss.org/browse/KEYCLOAK-5276
>>
>>
>> On Wed, Aug 9, 2017 at 5:06 PM Bruno Oliveira <bruno at abstractj.org> wrote:
>>
>>> A little bit late for the discussion, but today I was looking into this
>>> http://www.kitploit.com/2017/08/jwt-cracker-simple-hs256-jwt-token.html and
>>> wondering if we would be interesting to provide the same for client
>>> secrets. Just to prevent weak secrets.
>>>
>>> Of course this is out of the scope for this implementation. But maybe a
>>> nice to have.
>>>
>>> On Thu, Aug 3, 2017 at 11:31 AM Marek Posolda <mposolda at redhat.com>
>>> wrote:
>>>
>>>> My vote is to throw an error if password list cannot be found on the
>>>> filesystem. IMO it would be bad if admin has an impression that he just
>>>> successfully configured blacklist password policy even if it doesn't
>>>> work in reality. There should be rather error thrown, so admin is aware
>>>> that it doesn't work.
>>>>
>>>> However the biggest issue with the PR is another dependency as Hynek
>>>> pointed in PR and me in other thread.
>>>>
>>>> Marek
>>>>
>>>>
>>>> On 03/08/17 12:28, Thomas Darimont wrote:
>>>>> Hello,
>>>>>
>>>>> great that's just what I built :) here is the PR:
>>>>> https://github.com/keycloak/keycloak/pull/4370
>>>>>
>>>>> I'm not sure about the error handling if a configured password list
>>>>> cannot be found on the filesystem.
>>>>> https://github.com/keycloak/keycloak/pull/4370/files#diff-
>>>> 91236e069747f156edbd2c282fec8d92R78
>>>>> Looking forward to your feedback :)
>>>>>
>>>>> Cheers,
>>>>> Thomas
>>>>>
>>>>> 2017-08-03 12:11 GMT+02:00 Marek Posolda <mposolda at redhat.com
>>>>> <mailto:mposolda at redhat.com>>:
>>>>>
>>>>> +1 for filesystem.
>>>>>
>>>>> Marek
>>>>>
>>>>>
>>>>> On 29/07/17 10:06, Thomas Darimont wrote:
>>>>>
>>>>> Okay cool.
>>>>>
>>>>> Instead of storing the password blacklist in the database I
>>>>> could instead
>>>>> just refer to a password
>>>>> blacklist that lives on the file system.
>>>>>
>>>>> So Keycloak could ship with some of the lists from [0] and
>>>>> refer to those
>>>>> with a name like "default-blacklist1000",
>>>>> "default-blacklist-100000"
>>>>> in the BlacklistPasswordPolicy
>>>>> config
>>>>> within the admin-console.
>>>>>
>>>>> The "default-blacklist-100000" blacklist would then be mapped
>>>>> and resolve
>>>>> to
>>>>> something like
>>>>> "META-INF/password-blacklist/10_million_password_list_top_
>>>> 100000.txt".
>>>>> Users could provide their own blacklists with the provider
>>>>> config stored in
>>>>> standalone.xml
>>>>> than could then be adjusted via jboss-cli.
>>>>>
>>>>> I think this filesystem based approach is better than having
>>>>> to load and
>>>>> store big text-blobs in the database.
>>>>>
>>>>> Cheers,
>>>>> Thomas
>>>>>
>>>>> [0]
>>>>> https://github.com/danielmiessler/SecLists/tree/
>>>> master/Passwords
>>>>> <https://github.com/danielmiessler/SecLists/tree/
>>>> master/Passwords>
>>>>> Using those password lists seems to be allowed according to
>>>>> their license:
>>>>> https://www.owasp.org/index.php/Projects/OWASP_SecLists_
>>>> Project
>>>>> <https://www.owasp.org/index.php/Projects/OWASP_SecLists_
>>>> Project>
>>>>> which is Creative Commons Attribution ShareAlike 3.0 License
>>>>> -> IANAL but it seems to be useable in commercial products as
>>>> well
>>>>> https://creativecommons.org/licenses/by-sa/3.0/
>>>>> <https://creativecommons.org/licenses/by-sa/3.0/>
>>>>> as long as the authors are mentioned.
>>>>>
>>>>>
>>>>> 2017-07-28 22:03 GMT+02:00 Bill Burke <bburke at redhat.com
>>>>> <mailto:bburke at redhat.com>>:
>>>>>
>>>>> Yah, that sounds cool.
>>>>>
>>>>>
>>>>> On 7/28/17 11:48 AM, Thomas Darimont wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I build a configurable Password Policy that allows to
>>>>> match a given
>>>>> password against
>>>>> a blacklist with easy to guess passwords that should
>>>>> be not allowed as
>>>>>
>>>>> user
>>>>>
>>>>> passwords.
>>>>>
>>>>> The 'BlacklistPasswordPolicyProvider' can be
>>>>> configured via the admin UI
>>>>> with a ";" delimited list of easy to guess passwords.
>>>>>
>>>>> If the user / or admin want's to change the password
>>>>> it is checked
>>>>>
>>>>> against
>>>>>
>>>>> the blacklist.
>>>>> A password list can be found here:
>>>>> https://github.com/danielmiessler/SecLists/tree/
>>>> master/Passwords
>>>>> <https://github.com/danielmiessler/SecLists/tree/
>>>> master/Passwords>
>>>>> A blacklist is of course not a perfect solution but
>>>>> could still be useful
>>>>> for some users.
>>>>>
>>>>> Password blacklist would be compiled to a trie at
>>>>> startup (and on changes
>>>>> of the blacklist)
>>>>> for efficient lookups.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Cheers,
>>>>> Thomas
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.
>>>> jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
More information about the keycloak-dev
mailing list