Hacker News Reader

Comment by yonixw | Hacker News Reader

Bad against other cases such as constant length m (like user db id) that with combination of other weaknesses may be bruteforcable.

Like if your db is mongo and the 12 byte ID != 12 byte of secure randomness:

https://www.mongodb.com/docs/manual/reference/method/ObjectI...

I think the OP point still stands, just use HMAC instead of inventing crypto schemes.

View on HN

Even with HMAC you have to be careful! A contrived example:

    HMAC(secret, username || email)

Imagine you have `bob` and `bob@example.com` as inputs. This HMAC can trivially be reused (or learned) by registering `bobb` and `ob@example.com`.

If you ever have multiple fields being concatenated, use fixed-width length prefixes before each field:

   HMAC(secret, 0x0003 || bytes("bob") || 0x000e || bytes("bob@example.com"))

Does this really work? Any arbitrary fixed-length prefix?

I always just serialize the inputs with JSON or something. Any weirdness an attacker might try would just be escaped so they'll never be able to match the original input.

> I think the OP point still stands, just use HMAC instead of inventing crypto schemes.

Completely valid point, I was asking purely out of curiosity since this isn't my area of expertise but I find these kinds of vulnerabilities intriguing.

Reply on news.ycombinator.com