Jon Oberheide <j...@oberheide.org> added the comment: > 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 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14532> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
