passlib: long passwords trigger long checks
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
High
|
Morgan Fainberg | ||
Folsom |
Won't Fix
|
Undecided
|
Unassigned | ||
Grizzly |
Won't Fix
|
Undecided
|
Unassigned |
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.
Changed in keystone: | |
status: | New → Confirmed |
importance: | Undecided → High |
Changed in keystone: | |
assignee: | Dolph Mathews (dolph) → Lance Bragstad (ldbragst) |
Changed in keystone: | |
milestone: | none → havana-rc1 |
Changed in keystone: | |
assignee: | nobody → Morgan Fainberg (mdrnstm) |
Changed in keystone: | |
status: | Fix Committed → Fix Released |
Changed in keystone: | |
milestone: | havana-rc1 → 2013.2 |
This one is slightly more borderline, although I'm not convinced you could drive a DoS from it -- some valid keystone actions already take more than 2 seconds and hit I/O harder than this... so your stack has to survive those kind of requests anyway.
Adding the keystone core team so that we get their opinion on this.
(it's also a painful fix, because you don't want to break hypothetical long passwords on upgrades)