10:43 a.m.
I'd like for the next release (Beta-1) to be our last major feature
release. We'll shoot for early May as. I personally will be disrupted
1-2 weeks because of Red Hat Summit/DevNation
Must Have:
* Fine grain import/export of keycloak store
* LDAP/AD support
* Audit Log
* Acct Service oauth revocation
* Social login remember me
* Multi-tenant adapter abilities (for Travis)
* Any bootstrap requirements Aerogear needs
* Admin console needs to be rebrandable and support different themes.
This is an Aerogear requirement
* Server needs to be able to run on Resteasy 2.3.6 (EAP 6.x). A must if
we want to get keycloak into EAP through UPS.
Would like to have:
* Jira adapter. Have a good idea on how to implement, just need to find
the time or a volunteer.
* Tomcat, Jetty adapters
* Access control by IP Address and user geo location. i.e. block users
from logging in from China, or warn them. Google does a warning if
somebody logged into your account from China. Its how I found out how
somebody hacked my account a few years ago. i have a pretty good idea
on how to implement this, just need to find the time or a volunteer.
Anything major I'm missing?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11:20 a.m.
Must have:
* Brute force attack protection / Max failed login attempts
* Email notifications on certain events - related to audit log and your China warning
idea, but things like sending users an email when failed login attempts has occured
* Mobile adapters - I can sort out a Cordova adapter (it's just a wrapper for
keycloak.js), and we just need to document (maybe create examples) on how to use AeroGear
for iOS and Android native
Nice to have:
* Invalidate cookies for a specific device/browser through acct mngmt - for example if
someone used remember me option on a public machine by mistake they need to be able to
view devices/browsers with access, and invalidate specific machines
* Multi-factory authentication SPI, and implement add one more multi-factor auth type - to
show that we're not hard-coded to Google
* Installed application adapter - extract code from example into an adapter
* Rest endpoints for realm user management - non-admin access to users in a realm. Some
applications may want to be able to lookup users. Something like
'realm/<myrealm>/users'? Same as for account we'd have a few roles for a
'user-management' application that can be granted to users
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Thursday, 13 March, 2014 3:43:30 PM
Subject: [keycloak-dev] next release Beta 1 May timeframe
I'd like for the next release (Beta-1) to be our last major feature
release. We'll shoot for early May as. I personally will be disrupted
1-2 weeks because of Red Hat Summit/DevNation
Must Have:
* Fine grain import/export of keycloak store
* LDAP/AD support
* Audit Log
* Acct Service oauth revocation
* Social login remember me
* Multi-tenant adapter abilities (for Travis)
* Any bootstrap requirements Aerogear needs
* Admin console needs to be rebrandable and support different themes.
This is an Aerogear requirement
* Server needs to be able to run on Resteasy 2.3.6 (EAP 6.x). A must if
we want to get keycloak into EAP through UPS.
Would like to have:
* Jira adapter. Have a good idea on how to implement, just need to find
the time or a volunteer.
* Tomcat, Jetty adapters
* Access control by IP Address and user geo location. i.e. block users
from logging in from China, or warn them. Google does a warning if
somebody logged into your account from China. Its how I found out how
somebody hacked my account a few years ago. i have a pretty good idea
on how to implement this, just need to find the time or a volunteer.
Anything major I'm missing?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:53 a.m.
I would add to "Must have" this:
- Secured storage of private keys
- Address issues with "state" on TokenManager and SocialRequestManager
in memory. Would be useful for clustering, and to avoid memory leak
issues like https://issues.jboss.org/browse/KEYCLOAK-323
Marek
On 13.3.2014 17:20, Stian Thorgersen wrote:
Must have:
* Brute force attack protection / Max failed login attempts
* Email notifications on certain events - related to audit log and your China warning
idea, but things like sending users an email when failed login attempts has occured
* Mobile adapters - I can sort out a Cordova adapter (it's just a wrapper for
keycloak.js), and we just need to document (maybe create examples) on how to use AeroGear
for iOS and Android native
Nice to have:
* Invalidate cookies for a specific device/browser through acct mngmt - for example if
someone used remember me option on a public machine by mistake they need to be able to
view devices/browsers with access, and invalidate specific machines
* Multi-factory authentication SPI, and implement add one more multi-factor auth type -
to show that we're not hard-coded to Google
* Installed application adapter - extract code from example into an adapter
* Rest endpoints for realm user management - non-admin access to users in a realm. Some
applications may want to be able to lookup users. Something like
'realm/<myrealm>/users'? Same as for account we'd have a few roles for a
'user-management' application that can be granted to users
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: keycloak-dev(a)lists.jboss.org
> Sent: Thursday, 13 March, 2014 3:43:30 PM
> Subject: [keycloak-dev] next release Beta 1 May timeframe
>
> I'd like for the next release (Beta-1) to be our last major feature
> release. We'll shoot for early May as. I personally will be disrupted
> 1-2 weeks because of Red Hat Summit/DevNation
>
> Must Have:
>
> * Fine grain import/export of keycloak store
> * LDAP/AD support
> * Audit Log
> * Acct Service oauth revocation
> * Social login remember me
> * Multi-tenant adapter abilities (for Travis)
> * Any bootstrap requirements Aerogear needs
> * Admin console needs to be rebrandable and support different themes.
> This is an Aerogear requirement
> * Server needs to be able to run on Resteasy 2.3.6 (EAP 6.x). A must if
> we want to get keycloak into EAP through UPS.
>
> Would like to have:
> * Jira adapter. Have a good idea on how to implement, just need to find
> the time or a volunteer.
> * Tomcat, Jetty adapters
> * Access control by IP Address and user geo location. i.e. block users
> from logging in from China, or warn them. Google does a warning if
> somebody logged into your account from China. Its how I found out how
> somebody hacked my account a few years ago. i have a pretty good idea
> on how to implement this, just need to find the time or a volunteer.
>
>
> Anything major I'm missing?
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> 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
8:15 a.m.
On 3/14/2014 5:53 AM, Marek Posolda wrote:
I would add to "Must have" this:
- Secured storage of private keys
Ok.
- Address issues with "state" on TokenManager and
SocialRequestManager
in memory. Would be useful for clustering, and to avoid memory leak
issues like https://issues.jboss.org/browse/KEYCLOAK-323
we'll address this after beta 1. For beta 2 and final release I want to
focus on performance and clustering.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:49 a.m.
New subject: Brute force attack protection
FYI Working on Brute force login attack protection today. Last thing
I'll do until I spend a week on Resteasy.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12:40 p.m.
New subject: Brute force attack protection
The only good way to protect against brute force attacks is CAPTCHA or
IP Address ACLs. If you implement a delay, you can just have a
multi-threaded attack. If you disable the account after a number of
failed attempts, then you can have a DoS attack and bring down the whole
site.
On 3/14/2014 11:49 AM, Bill Burke wrote:
FYI Working on Brute force login attack protection today. Last
thing
I'll do until I spend a week on Resteasy.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
5:01 p.m.
New subject: Brute force attack protection
Ugh, seems that Captchas are easily broken too and also cause as much as
10% loss in leads/users. I've seen suggestions of a combination of IP
Address whitelists and blacklists per user and cross user.
1. If a user successfully logs in, add their IP address to the user's
whitelist.
2. After X failed login attempts per user, set the User's notBefore to
incrementally higher times on multiple failures. The notBefore check is
ignored for IP address on the user's whitelist.
The problem I see with this approach is that the attacker's IP might be
on the whitelist because of a proxy. There's also the problem with a
Gateway/Proxy screwing up the Server's idea of what the client IP is. I
know a Gateway/Proxy can set headers like "HTTP_X_FORWARDED_FOR". I'm
wondering if you can trust the Gateway/Proxy to remove
"HTTP_X_FORWARDED_FOR" headers sent by the client itself.
Do you think that is good enough? If the site wants better protection
then they should add two-factor auth. When we support certs, they
should require those too.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4:38 a.m.
New subject: Brute force attack protection
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Friday, 14 March, 2014 10:01:47 PM
Subject: Re: [keycloak-dev] Brute force attack protection
Ugh, seems that Captchas are easily broken too and also cause as much as
10% loss in leads/users. I've seen suggestions of a combination of IP
Address whitelists and blacklists per user and cross user.
1. If a user successfully logs in, add their IP address to the user's
whitelist.
2. After X failed login attempts per user, set the User's notBefore to
incrementally higher times on multiple failures. The notBefore check is
ignored for IP address on the user's whitelist.
The problem I see with this approach is that the attacker's IP might be
on the whitelist because of a proxy. There's also the problem with a
Gateway/Proxy screwing up the Server's idea of what the client IP is. I
know a Gateway/Proxy can set headers like "HTTP_X_FORWARDED_FOR". I'm
wondering if you can trust the Gateway/Proxy to remove
"HTTP_X_FORWARDED_FOR" headers sent by the client itself.
Wouldn't a blacklist be better? If a user fails to login from a certain IP address N
times add the IP to a blacklist?
I can see a few issues with a whitelist:
* Shared IP/NAT
* Public networks (anyone at a Starbucks is on the whitelist)
* Dynamic IP addresses (home broadband)
Do you think that is good enough? If the site wants better protection
then they should add two-factor auth. When we support certs, they
should require those too.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:06 a.m.
New subject: Brute force attack protection
On 3/17/2014 5:38 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: keycloak-dev(a)lists.jboss.org
> Sent: Friday, 14 March, 2014 10:01:47 PM
> Subject: Re: [keycloak-dev] Brute force attack protection
>
> Ugh, seems that Captchas are easily broken too and also cause as much as
> 10% loss in leads/users. I've seen suggestions of a combination of IP
> Address whitelists and blacklists per user and cross user.
>
>
> 1. If a user successfully logs in, add their IP address to the user's
> whitelist.
> 2. After X failed login attempts per user, set the User's notBefore to
> incrementally higher times on multiple failures. The notBefore check is
> ignored for IP address on the user's whitelist.
>
> The problem I see with this approach is that the attacker's IP might be
> on the whitelist because of a proxy. There's also the problem with a
> Gateway/Proxy screwing up the Server's idea of what the client IP is. I
> know a Gateway/Proxy can set headers like "HTTP_X_FORWARDED_FOR". I'm
> wondering if you can trust the Gateway/Proxy to remove
> "HTTP_X_FORWARDED_FOR" headers sent by the client itself.
Wouldn't a blacklist be better? If a user fails to login from a certain IP address N
times add the IP to a blacklist?
I can see a few issues with a whitelist:
* Shared IP/NAT
* Public networks (anyone at a Starbucks is on the whitelist)
* Dynamic IP addresses (home broadband)
Did a bit more research.
Blacklist has the same issues as a whitelist. What I think I'm going to
do is if there is a failure, wait to respond to the client for N
seconds. This let's successful logins immediately, but delays responses
from a failure. I'll also automatically wait N number of seconds if the
last failure was not that far back. (1 secs? 2 secs?)
This could cause a DoS, but could be mitigated greatly if we used Async
HTTP. Unfortunately, I believe EAP has a race condition with Async
HTTP. Need to find out if it was fixed.
We'll also keep a log of failures by IP that can be displayed in the
admin console. Allow the admin to create blacklists/whitelists. Allow
the admin to specify if headers like "X-Forwarded-For" can be trusted.
Allow admins to set up blocks/warnings by country IP.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:54 a.m.
New subject: Brute force attack protection
We could do the sleep on the client side. We'd set a flag on the account saying
it's disabled until some time in the future. If an account is locked we can display a
page that says wait N seconds (or something), and after N seconds redirect redirect to
login form using meta refresh.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Monday, 17 March, 2014 1:06:39 PM
Subject: Re: [keycloak-dev] Brute force attack protection
On 3/17/2014 5:38 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: keycloak-dev(a)lists.jboss.org
>> Sent: Friday, 14 March, 2014 10:01:47 PM
>> Subject: Re: [keycloak-dev] Brute force attack protection
>>
>> Ugh, seems that Captchas are easily broken too and also cause as much as
>> 10% loss in leads/users. I've seen suggestions of a combination of IP
>> Address whitelists and blacklists per user and cross user.
>>
>>
>> 1. If a user successfully logs in, add their IP address to the user's
>> whitelist.
>> 2. After X failed login attempts per user, set the User's notBefore to
>> incrementally higher times on multiple failures. The notBefore check is
>> ignored for IP address on the user's whitelist.
>>
>> The problem I see with this approach is that the attacker's IP might be
>> on the whitelist because of a proxy. There's also the problem with a
>> Gateway/Proxy screwing up the Server's idea of what the client IP is. I
>> know a Gateway/Proxy can set headers like "HTTP_X_FORWARDED_FOR".
I'm
>> wondering if you can trust the Gateway/Proxy to remove
>> "HTTP_X_FORWARDED_FOR" headers sent by the client itself.
>
> Wouldn't a blacklist be better? If a user fails to login from a certain IP
> address N times add the IP to a blacklist?
>
> I can see a few issues with a whitelist:
>
> * Shared IP/NAT
> * Public networks (anyone at a Starbucks is on the whitelist)
> * Dynamic IP addresses (home broadband)
>
Did a bit more research.
Blacklist has the same issues as a whitelist. What I think I'm going to
do is if there is a failure, wait to respond to the client for N
seconds. This let's successful logins immediately, but delays responses
from a failure. I'll also automatically wait N number of seconds if the
last failure was not that far back. (1 secs? 2 secs?)
This could cause a DoS, but could be mitigated greatly if we used Async
HTTP. Unfortunately, I believe EAP has a race condition with Async
HTTP. Need to find out if it was fixed.
We'll also keep a log of failures by IP that can be displayed in the
admin console. Allow the admin to create blacklists/whitelists. Allow
the admin to specify if headers like "X-Forwarded-For" can be trusted.
Allow admins to set up blocks/warnings by country IP.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:06 a.m.
New subject: Brute force attack protection
On 3/17/2014 9:54 AM, Stian Thorgersen wrote:
We could do the sleep on the client side. We'd set a flag on the
account saying it's disabled until some time in the future. If an account is locked we
can display a page that says wait N seconds (or something), and after N seconds redirect
redirect to login form using meta refresh.
This creates a very easy DoS opportunity.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:13 a.m.
New subject: Brute force attack protection
For a single user yes. Is that a big problem though?
If you sleep on the server you'd be able to do a DoS on the whole server (even if
async) with a single machine.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Monday, 17 March, 2014 2:06:43 PM
Subject: Re: [keycloak-dev] Brute force attack protection
On 3/17/2014 9:54 AM, Stian Thorgersen wrote:
> We could do the sleep on the client side. We'd set a flag on the account
> saying it's disabled until some time in the future. If an account is
> locked we can display a page that says wait N seconds (or something), and
> after N seconds redirect redirect to login form using meta refresh.
>
This creates a very easy DoS opportunity.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:23 a.m.
New subject: Brute force attack protection
Another thing, if someone really want to brute-force a specific account and they have a
botnet of 100K+ machines, a simple sleep of a few seconds isn't going to stop them. I
think the only way of doing that is to lock the account after N attempts.
----- Original Message -----
From: "Stian Thorgersen" <stian(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Monday, 17 March, 2014 2:13:13 PM
Subject: Re: [keycloak-dev] Brute force attack protection
For a single user yes. Is that a big problem though?
If you sleep on the server you'd be able to do a DoS on the whole server
(even if async) with a single machine.
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Monday, 17 March, 2014 2:06:43 PM
> Subject: Re: [keycloak-dev] Brute force attack protection
>
>
>
> On 3/17/2014 9:54 AM, Stian Thorgersen wrote:
> > We could do the sleep on the client side. We'd set a flag on the account
> > saying it's disabled until some time in the future. If an account is
> > locked we can display a page that says wait N seconds (or something), and
> > after N seconds redirect redirect to login form using meta refresh.
> >
>
> This creates a very easy DoS opportunity.
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:28 a.m.
New subject: Brute force attack protection
On 3/17/2014 10:13 AM, Stian Thorgersen wrote:
For a single user yes. Is that a big problem though?
I don't know. All the hacker needs to know is a list of emails and
could lock down a large set of users. Plus the users being hacked are
also locked out.
If you sleep on the server you'd be able to do a DoS on the whole
server (even if async) with a single machine.
Ugh, I guess the hacker could just ignore responses that are blocking.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3914
days inactive
3918
days old
13 comments
3 participants
participants (3)
-
Bill Burke -
Marek Posolda -
Stian Thorgersen