Open Stack

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.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1175906

Title:
  passlib: long passwords trigger long checks

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  Grant Murphy originally reported:

  * Denial of Service

    The passlib restriction of 4096 for maximum password length is 
    potentially too generous for production environments. On my local machine
    the sha512_crypt algorithm with input of 4096 and 40000
    rounds will potentially introduce a DOS problem:
         feasible length(128) password encrypt:  0.0707409381866  seconds
         feasible length(128) password verify:  0.140727996826  seconds
         excessive length(4096) password encrypt:  1.33277702332  seconds
         excessive length(4096) password verify:  2.66491699219  seconds

  
    I would consider tweaking these values (length or rounds) to reduce 
    the computational overhead here or you're probably going to have a bad time.

  If this is exploitable it will need a CVE, if not we should still
  harden it so it can't be monkeyed with in the future.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1175906/+subscriptions