Re: [openstack-dev] [keystone][security] New BP for anti brute force in keystone

[Julien Danjou]

On Wed, Jan 13 2016, Morgan Fainberg wrote:

> A standard method of rate limiting for OpenStack services would be a good
> thing to figure out.

Apache used as a daemon for WSGI application (e.g. like we do by default
in devstack) has support for rate limit for decades – see mod_ratelimit
for example.
So this is a problem we really want to solve in OpenStack – unless we're
really getting bored or victims of the NIH syndrom.

Now, that does mean that other protection methods (as suggested in the
original blueprint proposal) should not be implemented, but this one
shouldn't be reinvented for sure.

Cheers,
-- 
Julien Danjou
# Free Software hacker
# https://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][security] New BP for anti brute force in keystone

[Jordan Pittier]

Hi,
Can't you just do some rate limiting at your webserver level ?

On Tue, Jan 12, 2016 at 3:55 PM, McPeak, Travis 
wrote:

> One issue to be aware of is the use of this as a Denial of Service
> vector.  Basically an attacker can use this to lock out key accounts
> by continuously sending invalid passwords.
>
> Doing this might have unexpected and undesirable results,
> particularly in automated tasks.
>
> I think this feature has some definite uses, but we should definitely
> think through use and abuse cases, and probably allow a list of
> accounts that this should not be active for.
>
>
> -Travis
>
> On 1/12/16, 3:11 AM, "openstack-dev-requ...@lists.openstack.org" <
> openstack-dev-requ...@lists.openstack.org> wrote:
>
> >I have registered a new bp for keystone with the capability of anti brute
> force
> >
> >
> >Problem Description:
> >the attacks of account are increasing in the cloud
> >the attacker steals the account information by guessing the password in
> brute force.
> >therefore, the ability of account in anti brute force is necessary.
> >
> >proposed Change:
> >1. add two configure properties for keystone: threshold for times of
> password error consecutively, time of locked when password error number
> reaches the threshold.
> >2. add two properties of user information in times of password
> consecutive errors, and last password error time. when the password of an
> account error consecutively reaches threshold, the account will be locked
> with a few time.
> >3. locked account will unlock automatically when locked status time out
> >4. the APIs of keystone which use user_name and password for
> authentication, the message of response will add an error description when
> the account is locked
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][security] New BP for anti brute force in keystone

[Morgan Fainberg]

A standard method of rate limiting for OpenStack services would be a good
thing to figure out.
On Jan 13, 2016 02:56, "Jordan Pittier"  wrote:

> Hi,
> Can't you just do some rate limiting at your webserver level ?
>
> On Tue, Jan 12, 2016 at 3:55 PM, McPeak, Travis 
> wrote:
>
>> One issue to be aware of is the use of this as a Denial of Service
>> vector.  Basically an attacker can use this to lock out key accounts
>> by continuously sending invalid passwords.
>>
>> Doing this might have unexpected and undesirable results,
>> particularly in automated tasks.
>>
>> I think this feature has some definite uses, but we should definitely
>> think through use and abuse cases, and probably allow a list of
>> accounts that this should not be active for.
>>
>>
>> -Travis
>>
>> On 1/12/16, 3:11 AM, "openstack-dev-requ...@lists.openstack.org" <
>> openstack-dev-requ...@lists.openstack.org> wrote:
>>
>> >I have registered a new bp for keystone with the capability of anti
>> brute force
>> >
>> >
>> >Problem Description:
>> >the attacks of account are increasing in the cloud
>> >the attacker steals the account information by guessing the password in
>> brute force.
>> >therefore, the ability of account in anti brute force is necessary.
>> >
>> >proposed Change:
>> >1. add two configure properties for keystone: threshold for times of
>> password error consecutively, time of locked when password error number
>> reaches the threshold.
>> >2. add two properties of user information in times of password
>> consecutive errors, and last password error time. when the password of an
>> account error consecutively reaches threshold, the account will be locked
>> with a few time.
>> >3. locked account will unlock automatically when locked status time out
>> >4. the APIs of keystone which use user_name and password for
>> authentication, the message of response will add an error description when
>> the account is locked
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][security] New BP for anti brute force in keystone

[Morgan Fainberg]

This needs to be proposed as a spec, not just a blueprint.

For what it is worth, this has been discussed many times and it was
determined that keystone as a project was not interested in really managing
the life cycle of passwords on this front. Since we support the use of real
Identity Stores and Identity Providers that have this functionality,
password life cycle (complexity, minimum number of passwords before reuse,
minimum/max life span of passwords) instead of the local sql-store, we were
going to rely on these (LDAP Identity, federated identity, etc).

It was also determined that if we were going to go down the path of being a
full-featured identity store/provider in SQL we need clear
support/commitment from orgs to help maintain these features as it is a
significant scope increase to the Identity Store; adding in password
lockouts is just the tip of the iceberg and we need to consider all the
functionality as well.

So, in short:

* This is not a bad conversation to have again. It is worth considering as
a conversation for the next summit in my opinion.

* it needs to be a spec (proposed to the Identity-specs repo).

I look forward to seeing where this goes.

--Morgan
On Jan 11, 2016 23:32, "Youwenwei"  wrote:

> I have registered a new bp for keystone with the capability of anti brute
> force
>
>
>
> Problem Description:
> the attacks of account are increasing in the cloud
> the attacker steals the account information by guessing the password in
> brute force.
> therefore, the ability of account in anti brute force is necessary.
>
> proposed Change:
> 1. add two configure properties for keystone: threshold for times of
> password error consecutively, time of locked when password error number
> reaches the threshold.
> 2. add two properties of user information in times of password consecutive
> errors, and last password error time. when the password of an account error
> consecutively reaches threshold, the account will be locked with a few time.
> 3. locked account will unlock automatically when locked status time out
> 4. the APIs of keystone which use user_name and password for
> authentication, the message of response will add an error description when
> the account is locked
>
>
>
> https://blueprints.launchpad.net/keystone/+spec/anti-brute-force
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][security] New BP for anti brute force in keystone

[McPeak, Travis]

One issue to be aware of is the use of this as a Denial of Service
vector.  Basically an attacker can use this to lock out key accounts
by continuously sending invalid passwords.

Doing this might have unexpected and undesirable results,
particularly in automated tasks.

I think this feature has some definite uses, but we should definitely
think through use and abuse cases, and probably allow a list of
accounts that this should not be active for.


-Travis

On 1/12/16, 3:11 AM, "openstack-dev-requ...@lists.openstack.org" 
 wrote:

>I have registered a new bp for keystone with the capability of anti brute force
>
>
>Problem Description:
>the attacks of account are increasing in the cloud
>the attacker steals the account information by guessing the password in brute 
>force.
>therefore, the ability of account in anti brute force is necessary.
>
>proposed Change:
>1. add two configure properties for keystone: threshold for times of password 
>error consecutively, time of locked when password error number reaches the 
>threshold.
>2. add two properties of user information in times of password consecutive 
>errors, and last password error time. when the password of an account error 
>consecutively reaches threshold, the account will be locked with a few time.
>3. locked account will unlock automatically when locked status time out
>4. the APIs of keystone which use user_name and password for authentication, 
>the message of response will add an error description when the account is 
>locked

smime.p7s
Description: S/MIME cryptographic signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone][security] New BP for anti brute force in keystone

[Youwenwei]

I have registered a new bp for keystone with the capability of anti brute force


Problem Description:
the attacks of account are increasing in the cloud
the attacker steals the account information by guessing the password in brute 
force.
therefore, the ability of account in anti brute force is necessary.

proposed Change:
1. add two configure properties for keystone: threshold for times of password 
error consecutively, time of locked when password error number reaches the 
threshold.
2. add two properties of user information in times of password consecutive 
errors, and last password error time. when the password of an account error 
consecutively reaches threshold, the account will be locked with a few time.
3. locked account will unlock automatically when locked status time out
4. the APIs of keystone which use user_name and password for authentication, 
the message of response will add an error description when the account is locked

https://blueprints.launchpad.net/keystone/+spec/anti-brute-force


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev