[issue15061] hmac.secure_compare() leaks information about length of strings

[Maciej Fijalkowski]

Maciej Fijalkowski <fijall at gmail.com> added the comment:

On Fri, Jun 15, 2012 at 9:55 AM, Hynek Schlawack <report at bugs.python.org>wrote:

>
> Hynek Schlawack <hs at ox.cx> added the comment:
>
> >> and any other place that compares passwords, tokens, …
> >
> > No no no. Any sensible place to compare passwords would use some
> > sort of one-way function (password hash) before the comparison,
> > so that someone breaking into the machine will not gain the clear
> > text passwords.
>
> I agree that this is the right way to do. However I disagree that it's
> also the only sensible way to do in the real world. Sometimes you just
> _have_ to compare sensitive strings, whether you like it or not.
>
> I see your point that adding such a function would leverage bad security
> behavior and thus may be a bad thing. The usefulness of such a function to
> some(?) people is IMHO not disputable though.
>

Note that this does not relief you from using a time-independent comparison
function. If you call some hash function (which time is known to the
attacker), then you compare it against a stored hashed version. If you use
a normal compare you're leaking the hash. This is indeed not as bad as
leaking the password, but it has been demonstrated that one-direction
functions are still vulnerable to some sort of attacks, so it's not ideal
either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15061>
_______________________________________