Re: [VOTE] Timing attack safe string comparison function
| From: | Yasuo Ohgaki | Date: | Thu, 06 Feb 2014 05:17:18 +0000 |
| Subject: | Re: [VOTE] Timing attack safe string comparison function | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-72318@lists.php.net to get a copy of this message | ||
It's me again.
On Thu, Feb 6, 2014 at 1:31 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Sorry for multiple posts.
>
> On Thu, Feb 6, 2014 at 1:20 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
>> Since comparison of short and/or not hashed data (e.g. user supplied raw
>> password) should
>> not be done as the function name imply, we may better to document so that
>> users always
>> compare hashed values even when they store raw password/etc.
>> So randomized delay may be overkill.
>>
>
> Because user should not pass other than hashed values, we may
> return FALSE simply when length mismatches. Generated hashed
> length should not be a secret. This get rid of length leak issue and
> the function name is good for this purpose and make the operation
> always constant.
>
Since there is internal code that is vulnerable to timing attack,
could you make it PHPAPI?
For example, ext/session/mod_mm.c is comparing session ID using strcmp()
for (prev = NULL, ret = data->hash[slot]; ret; prev = ret, ret =
ret->next) {
if (ret->hv == hv && !strcmp(ret->key, key)) {
break;
}
}
Regards,
P.S. Other save handlers are also vulnerable to timing attack.
It could be mitigated the attack by specifying minimum length of session
ID. I'll add this new INI option to session module.
--
Yasuo Ohgaki
yohgaki@ohgaki.net