Message158045
> One thing that could definitely be interesting is to look through the
> code base and example to see if a similar - but vulnerable - pattern
> is used, and fix such occurrences.
Based on some quick greps, I didn't see many internal users of hmac and the current users don't seem to use it in a scenario that would be at risk (eg. attacker supplied digest compared against an expected digest).
Given that this issue has affected a lot of security-sensitive third-party code (keyczar, openid providers, almost every python web service that implements "secure cookies" [1] or other HMAC-based REST API signatures), I do like the idea of adding a warning in the relevant documentation as sbt proposed.
The only reason I'd recommend _not_ putting a time_independent_comparison() function in the hmac module is that it's not really HMAC-specific. In practice, any fixed-length secrets should be compared in a time-independent manner. It just happens that HMAC verification is a pretty common case for this vulnerable construct. :-)
[1] https://github.com/facebook/tornado/blob/master/tornado/web.py#L1981 |
|
Date |
User |
Action |
Args |
2012-04-11 15:29:27 | Jon.Oberheide | set | recipients:
+ Jon.Oberheide, vstinner, r.david.murray, neologix, sbt |
2012-04-11 15:29:27 | Jon.Oberheide | set | messageid: <1334158167.22.0.330276758065.issue14532@psf.upfronthosting.co.za> |
2012-04-11 15:29:26 | Jon.Oberheide | link | issue14532 messages |
2012-04-11 15:29:26 | Jon.Oberheide | create | |
|