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
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
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
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
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
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