Message162861
| 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. |
|