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
F3536685: D9242.id31589.diff
Wed, Dec 25, 6:42 PM
F3531278: D9242.diff
Wed, Dec 25, 7:00 AM
Unknown Object (File)
Sat, Dec 21, 2:09 PM
Unknown Object (File)
Sat, Dec 21, 2:09 PM
Unknown Object (File)
Sat, Dec 21, 2:08 PM
Unknown Object (File)
Sat, Dec 21, 2:00 PM
Unknown Object (File)
Nov 20 2024, 11:18 PM
Unknown Object (File)
Nov 15 2024, 2:23 AM
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
No Lint Coverage
Unit
No Test Coverage

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