3 ms·
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 an
by yonixw 3y ago
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/ObjectId/ https://www.mongodb.com/docs/manual/reference/method/ObjectI...
I think the OP point still stands, just use HMAC instead of inventing crypto schemes.
- stouset 3y agoEven 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"))
- erhaetherth 3y agoDoes 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.
- smarkov 3y ago> 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.