Re: [RFC] Timing attack safe string comparison function

From: Date: Fri, 27 Dec 2013 18:12:23 +0000
Subject: Re: [RFC] Timing attack safe string comparison function
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-70882@lists.php.net to get a copy of this message
On 27 December 2013 05:57, Sara Golemon <pollita@php.net> wrote: > However, I do worry about using this syntax for a couple reasons of > unintended consequences: > > * Fat Fingers: A third int/bool field to strcmp() could very easily > get misinterpreted by accidentally using strncmp(). Now that > true/0x01 looks like a length of 1 and your strcmp() only has to match > the first character! This does worry me a little too. Another reason I'm not thrilled with the idea of adding a parameter is that I think it's clearer what's going on if the function name itself is descriptive (provided a good name can be found) — fundamentally, they're actually different operations, even if they're in the class of "string comparison functions", and if you're switching out the entire implementation based on a mode parameter, that suggests to me they should be different functions. > Lastly, please stay away from names like "strcmp_secure()". 5-10 > years from now such a function will inevitably turn out to be insecure > in some way and we'll need to add > strcmp_really_secure_I_mean_it_this_time(). That way lies madness. +1. I don't know what a good name is, but anything with the word "secure" isn't it. str_compare_constant_time()? Adam

« previous php.internals (#70882) next »