[kwlug-disc] Postgresql hash index as a mitigation of timing attack

[Mikalai Birukou]

Context (as a follow up to Hadi's presentation on the 4-th of June):

Sometimes we store secret session ids in db, and we use these for 
authentication. Usually there is query that get respective record, 
searching a table for a given by user session id.
Usual `WHERE` clause uses the most fast comparison, which run timing is 
dependent on input values. This can be used as a base for an attack with 
session id guessing via timing.

Question:

Hadi, and others, will hash index work as a quick fix here?

1) Should ensure that a query, abusable by an attack, always uses index.

2) Index on a secret (e.g. session id) is a hash index. I assume it 
means that provided by a user (attacker) value is hashed, and fast 
comparison will occur on hashes.
Hashes that are close to each other, like `a...`, `aD...`, `aDf...`, 
which is a guessing sequence will be coming from values that are not 
very close to each other. Unless hash has a simple unhash function, 
there seem to be no way to arrange guessing sequence on an attacking side.

If both 1 and 2 are achievable, then a simple switch to hash index can 
be a mitigation.
Whereas, the other way, as heard on one of ProtonMail's tech talks, is 
for developer to split a secret token into two part, with only first 
part being used in `WHERE` clause, while biz app does constant time 
comparison of the second part.