This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author fijall
Recipients arigo, christian.heimes, fijall, hynek, loewis, ncoghlan, pitrou
Date 2012-06-15.07:58:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAK5idxSDwEaEVMPt+3762FHaPaSoFn3=JH2kaDtab16b999qeg@mail.gmail.com>
In-reply-to <F8C6B640-C4CE-4FDF-8805-D2AD2DA160FF@ox.cx>
Content
On Fri, Jun 15, 2012 at 9:55 AM, Hynek Schlawack <report@bugs.python.org>wrote:

>
> Hynek Schlawack <hs@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.
History
Date User Action Args
2012-06-15 07:58:29fijallsetrecipients: + fijall, loewis, arigo, ncoghlan, pitrou, christian.heimes, hynek
2012-06-15 07:58:29fijalllinkissue15061 messages
2012-06-15 07:58:28fijallcreate