hash-or-encrypt.md

Via Twitter

Authors consider SQLi as main attack vector. Hashed token mitigate r/o SQLi, encrypted mitigate r/w SQLi

That actually doesn't buy you anything. Consider the following table schema:

CREATE TABLE reset_tokens (
    tokenid BIGSERIAL PRIMARY KEY,
    selector TEXT,
    verifier TEXT,
    user BIGINT REFERENCES users (userid),
    expires TIMESTAMP
);

We recommended hashing the verifier. You might think encryption would mitigate against read/write SQLi, but you can do this:

1. Issue a reset for an unprivileged user.
2. UPDATE reset_tokens SET user = {$target} WHERE selector = {$knownToAttacker}
3. Access the URL.

That works even if you can't just break out of the database, into the filesystem, and exfiltrate their encryption keys.

Why not just specify HMAC-SHA256(message=userid, key=verifier) instead of SHA256(verifier)? Then we can avoid the headache that is JWT. :)

@paragonie-scott, hm. It seems you are right. "brevity is the soul of wit" :)

Out of curiosity: Why JWT specifically? What does JWT offer that you can't solve with hash_hmac() and hash_equals()?

store the same token wrapped with encryption

I don't really see a need for encryption. All you need is, given a threat model of UPDATE queries, message integrity. That's what HMAC offers.

This scheme seems to mitigate most of confidentiality and integrity threats with good crypto that is under developer control.

What's "good crypto" about JWT that isn't offered by HMAC?

@paragonie-scott, may be not: verifier is know to attacker. so he can produce HMAC(message=victim-user-id, key=attacker-verifier), right?

@paragonie-scott, by good crypto I meant something opposed to splitting verifier.

IMHO we can rely on HMAC if key is secret and not known to attacker. E.g. storing something like HMAC(message={userid, verifier}, key=system-secret).

Yes, that's a good point. :)