Comment 29 for bug 1175906

I am a bit late to the party but here are my suggestions,

1. Rate limiting should be implemented with a high priority. (e.g. Gmail shows a CAPTCHA if you keep entering wrong password).
    In KeyStone case, this rate limited should also be applied even if the authentication succeeds, for best results.

   I am not sure about the "layer" at which these rate limiting features should be implemented though.

2. "iterations" in the hashing algorithm can be reduced by a factor of 25 if the minimum password length is increased by 1.
    See http://blog.agilebits.com/2012/07/31/1password-is-ready-for-john-the-ripper/

3. Ideally, a configurable hashing algorithm (like Django's PBKDF2-HMAC-SHA256 or better) should be used which allows tweaking of the "iterations" parameter to attain the desired balance.

* I have written a DoS tool which is able to saturate a KeyStone server with almost zero bandwidth and CPU consumption.