3 ms·
Do you think it's correct to claim that hashids are not reversible, if the attacker is unable to choose the plain text to be encoded? [1] [1] In other words, t
by ngrilly 8y ago
Do you think it's correct to claim that hashids are not reversible, if the attacker is unable to choose the plain text to be encoded? [1]
[1] In other words, the sequential IDs are generated server-side and the attacker has not control over them.
- eximius 8y agoThis is how we use them. It should be fine. That said, they should probably not be used for anything sensitive. Obscuring a database id is probably fine, as a password has no.
- _hyn3 8y ago> Obscuring a database id is probably fine If you can guess what the next database ID is, then you can probably use it to take over the cookie session ID, use it in a replay attack, or whatever, depending on how your app is architected. ... if you don't need to keep something secret, then why hash it at all? And if you do, then actually hash it.
- eximius 8y agoI'll tell you for free that our cookies don't use an auto incrementing id. If you have an asset that is accessed by id, it is beneficial to have a secure, reversable function so that you can prevent trivial crawling while maintaining ease of development. We don't allow chosen plaintexts, so the cryptanalysis here is not relevant. And, even if it did break our use, it would deter most.