[Pharo-project] PasswordHashingFFI package - users should update
Hi - I was using a basic string comparison in the #checkPassword:against: methods and I now understand that that is susceptible to a timing attack on some systems (http://codahale.com/a-lesson-in-timing-attacks/). I'm not sure these types of attack apply to Smalltalk environments or not but its not hard to implement a constant time algorithm. Instead of failing on the first unmatched character it reports passing/failing after checking all characters in the hashes. I think the new version is not susceptible to the timing attacks mentioned in the linked article and if you use the package mentioned in the subject you should update to the latest version. Thanks Paul
Thanks for sending us this link. It is quite interesting. Did the people think about using random generated number to change the response time? On Jan 14, 2013, at 9:32 PM, Paul DeBruicker wrote:
Hi -
I was using a basic string comparison in the #checkPassword:against: methods and I now understand that that is susceptible to a timing attack on some systems (http://codahale.com/a-lesson-in-timing-attacks/). I'm not sure these types of attack apply to Smalltalk environments or not but its not hard to implement a constant time algorithm.
Instead of failing on the first unmatched character it reports passing/failing after checking all characters in the hashes.
I think the new version is not susceptible to the timing attacks mentioned in the linked article and if you use the package mentioned in the subject you should update to the latest version.
Thanks
Paul
On 14.01.2013 22:38, Stéphane Ducasse wrote:
Thanks for sending us this link. It is quite interesting.
Did the people think about using random generated number to change the response time? Network latency, processor scheduling etc. already add a measure of randomness to the returned values, so the attack already presumes you are able to induce the actual signal from noisy results. Adding another random factor doesn't really change that, it just means one would have to adjust how the actual signal is extracted.
Cheers, Henry
ok so constant time to answer is better. Stef On Jan 15, 2013, at 9:16 AM, Henrik Sperre Johansen wrote:
On 14.01.2013 22:38, Stéphane Ducasse wrote:
Thanks for sending us this link. It is quite interesting.
Did the people think about using random generated number to change the response time? Network latency, processor scheduling etc. already add a measure of randomness to the returned values, so the attack already presumes you are able to induce the actual signal from noisy results. Adding another random factor doesn't really change that, it just means one would have to adjust how the actual signal is extracted.
Cheers, Henry
participants (3)
-
Henrik Sperre Johansen -
Paul DeBruicker -
Stéphane Ducasse