Skip to content

Instantly share code, notes, and snippets.

Last active September 22, 2016 20:18
What would you like to do?

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 (
    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.

Copy link

paragonie-scott commented Sep 21, 2016

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?

Copy link

adedov commented Sep 21, 2016

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

Copy link

adedov commented Sep 21, 2016

@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).

Copy link

Yes, that's a good point. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment