Page MenuHomePhabricator

[services-lib] Use constant-time-eq for token verification
ClosedPublic

Authored by bartek on Sep 20 2023, 2:50 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Oct 27, 4:14 AM
Unknown Object (File)
Tue, Oct 22, 7:17 PM
Unknown Object (File)
Sun, Oct 13, 7:54 PM
Unknown Object (File)
Sun, Oct 13, 7:54 PM
Unknown Object (File)
Sun, Oct 13, 7:53 PM
Unknown Object (File)
Sun, Oct 13, 7:48 PM
Unknown Object (File)
Sat, Oct 12, 7:27 AM
Unknown Object (File)
Sat, Oct 5, 7:49 PM
Subscribers

Details

Summary

verify_access_token in Identity Service does this so probably we should do it here too.

Depends on D9241

Test Plan

I did some simple comparisons and it seems to work fine.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

bartek held this revision as a draft.
bartek published this revision for review.Sep 20 2023, 3:02 AM

I'm not really familiar with this stuff, so I might be completely wrong but:

From the contant_time_eq docs:

// Not equal-sized, so won't take constant time.
assert!(!constant_time_eq(b"foo", b""));

We don't check the length anywhere so couldn't the attacker start by sending a one-byte token, and after they find a match send a two-byte token, etc...?

For context the comment from https://phab.comm.dev/D4199?id=13456#inline-26218:

[without using the constant_time_eq] This introduces a timing side channel attack where the attacker can extract information about how much of the request token is right by the amount of time the comparison takes

after they find a match

i'm not sure what you mean by this. an attacker could learn the length of the token, but that's not a big deal - there'd still be enough entropy for a proper token

This revision is now accepted and ready to land.Sep 20 2023, 11:22 PM

Ok, seems like constant_time_eq checks the lengths inside, from looking at the code