4 ms·
Compulsory plug when someone uses macaroons: using an HMAC is overkill. See https://github.com/rustyrussell/runes https://github.com/rustyrussell/runes for a s
by RustyRussell 3y ago
Compulsory plug when someone uses macaroons: using an HMAC is overkill.
See https://github.com/rustyrussell/runes https://github.com/rustyrussell/runes for a simpler alternative and implementation (this has C and Python, but there's also a Rust implementation because why not?)
However, the "no db access" property has proven to be untenable in practice. Users end up wanting to see what runes are issued, blacklist them, know when they were last used, and have rate limits. The last two are a killer, requiring some state to be kept (unless your system allows you to return a modified rune to the user, which is a different workflow from normal bearer creds).
- RustyRussell 3y agoOops, I read further: you did use unique ids, and blacklists! I did that too. Now you're not db-lookup-free on use, so you need to think hard about what all this actually gains :(
- BoppreH 3y agoHuh, I never thought about using length extension attacks as a protocol feature. However, you still need the initial secret, analogous to the HMAC key, and it's not a complicated algorithm to justify much effort in removing. And don't forget that HMAC is more resistant to collision than the underlying hash. For example, I think it's still unknown if HMAC-MD5 is weak, even though MD5 definitely is.