10:48 a.m.
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
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
1:52 p.m.
Hello,
just realized that I cannot store large strings as the value for the
password policy since
all password policy configurations are stored as a concatenated string in
the
password_policy column of the realm table which has a maximum capacity of
2550 characters :-/
Values look like:
"hashIterations and passwordHistory and passwordBlacklist(bubu;foo;bar;baz)"
One could change the column type to "text" which is "not limited" but
I
think it would be
better to use something else for storing such values - the component_config
table perhaps?
Thoughts?
Thomas
2017-07-28 17:48 GMT+02:00 Thomas Darimont <thomas.darimont(a)googlemail.com>:
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
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
3:03 p.m.
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
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:06 a.m.
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
Using those password lists seems to be allowed according to their license:
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/
as long as the authors are mentioned.
2017-07-28 22:03 GMT+02:00 Bill Burke <bburke(a)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
>
> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:11 a.m.
+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
Using those password lists seems to be allowed according to their license:
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/
as long as the authors are mentioned.
2017-07-28 22:03 GMT+02:00 Bill Burke <bburke(a)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
>>
>> 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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:28 a.m.
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-91236e069747f15...
Looking forward to your feedback :)
Cheers,
Thomas
2017-08-03 12:11 GMT+02:00 Marek Posolda <mposolda(a)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
> Using those password lists seems to be allowed according to their license:
> 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/
> as long as the authors are mentioned.
>
>
> 2017-07-28 22:03 GMT+02:00 Bill Burke <bburke(a)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
>>>
>>> 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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
9:04 a.m.
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-91236e069747f15...
Looking forward to your feedback :)
Cheers,
Thomas
2017-08-03 12:11 GMT+02:00 Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@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(a)redhat.com
<mailto:bburke@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(a)lists.jboss.org
<mailto:keycloak-dev@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(a)lists.jboss.org
<mailto:keycloak-dev@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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
3:06 p.m.
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(a)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-91236e069747f15...
>
> Looking forward to your feedback :)
>
> Cheers,
> Thomas
>
> 2017-08-03 12:11 GMT+02:00 Marek Posolda <mposolda(a)redhat.com
> <mailto:mposolda@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(a)redhat.com
> <mailto:bburke@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(a)lists.jboss.org
> <mailto:keycloak-dev@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(a)lists.jboss.org
> <mailto:keycloak-dev@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(a)lists.jboss.org <mailto:
keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:32 p.m.
Good point! Thanks for the hint Bruno :)
2017-08-09 22:06 GMT+02:00 Bruno Oliveira <bruno(a)abstractj.org>:
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(a)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(a)redhat.com
> > <mailto:mposolda@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(a)redhat.com
> > <mailto:bburke@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(a)lists.jboss.org
> > <mailto:keycloak-dev@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(a)lists.jboss.org
> > <mailto:keycloak-dev@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(a)lists.jboss.org <mailto:keycloak-dev@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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
6:03 a.m.
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(a)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(a)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-91236e069747f15...
> >
> > Looking forward to your feedback :)
> >
> > Cheers,
> > Thomas
> >
> > 2017-08-03 12:11 GMT+02:00 Marek Posolda <mposolda(a)redhat.com
> > <mailto:mposolda@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(a)redhat.com
> > <mailto:bburke@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(a)lists.jboss.org
> > <mailto:keycloak-dev@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(a)lists.jboss.org
> > <mailto:keycloak-dev@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(a)lists.jboss.org <mailto:
> keycloak-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
12:44 p.m.
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...
Cheers,
Thomas
2017-08-10 13:03 GMT+02:00 Bruno Oliveira <bruno(a)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(a)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(a)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(a)redhat.com
>> > <mailto:mposolda@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(a)redhat.com
>> > <mailto:bburke@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(a)lists.jboss.org
>> > <mailto:keycloak-dev@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(a)lists.jboss.org
>> > <mailto:keycloak-dev@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(a)lists.jboss.org <mailto:keycloak-dev@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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
10:48 a.m.
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...
Cheers,
Thomas
2017-08-10 13:03 GMT+02:00 Bruno Oliveira <bruno(a)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(a)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(a)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(a)redhat.com
>>>> <mailto:mposolda@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(a)redhat.com
>>>> <mailto:bburke@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(a)lists.jboss.org
>>>> <mailto:keycloak-dev@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(a)lists.jboss.org
>>>> <mailto:keycloak-dev@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(a)lists.jboss.org <mailto:keycloak-dev@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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2650
days inactive
2664
days old
11 comments
4 participants
participants (4)
-
Bill Burke -
Bruno Oliveira -
Marek Posolda -
Thomas Darimont