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

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