4 ms·

To me security by obscurity is limited to things like this: There is a way to view bananas at /bananas/:bananaUUID unsecured endpoint. I don’t want people t

To me security by obscurity is limited to things like this: There is a way to view bananas at /bananas/:bananaUUID unsecured endpoint. I don’t want people to get all my banana data, but as long as there isn’t an easy way to list banana uuids, that endpoint is basically effective security by obscurity.

disruptiveink 3y ago
That's an unfortunately common misconception. Your example is not security though obscurity any more than password authentication is, though. Security through obscurity means substituting security for a flawed algorithm that is usually trivial to exploit if the attacker is made aware of the algorithm. Think things like no authentication and ROT13ing and Base64ing clientside. If the method leaks or is discovered, the whole system is broken. You just told me your algorithm and I cannot get to your banana because the UUID key space is insanely large. So that's not security to obscurity.
a16r 3y ago
OWASP has some specific guidance on this while clarifying the need for access controls: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html#identifier-complexity https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Dire...
mdavidn 3y ago
There are some important caveats to consider: Client and server software will not handle URLs like secrets, so UUIDs will leak out through various channels. Some examples include logs, user analytics, ad networks, browser history, bookmarks, e-mail, instant messages, shady browsers, shady ISPs, referrer headers, etc. You cannot rotate resource identifiers without breaking clients, so a leaked URL is permanently leaked. Hopefully you're using version 4 UUIDs. Those set aside 6 bits to encode UUID details, keeping 122 bits of entropy. Since every banana needs its own identifier, subtract the number of bits needed to uniquely represent bananas. What's left will unavoidably be less guess-resistant than client secrets. Other versions of UUID use many more bits for low-entropy purposes.

disruptiveink 3y ago

That's an unfortunately common misconception. Your example is not security though obscurity any more than password authentication is, though. Security through obscurity means substituting security for a flawed algorithm that is usually trivial to exploit if the attacker is made aware of the algorithm. Think things like no authentication and ROT13ing and Base64ing clientside. If the method leaks or is discovered, the whole system is broken. You just told me your algorithm and I cannot get to your banana because the UUID key space is insanely large. So that's not security to obscurity.

a16r 3y ago

OWASP has some specific guidance on this while clarifying the need for access controls: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html#identifier-complexity https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Dire...

mdavidn 3y ago

There are some important caveats to consider: Client and server software will not handle URLs like secrets, so UUIDs will leak out through various channels. Some examples include logs, user analytics, ad networks, browser history, bookmarks, e-mail, instant messages, shady browsers, shady ISPs, referrer headers, etc. You cannot rotate resource identifiers without breaking clients, so a leaked URL is permanently leaked. Hopefully you're using version 4 UUIDs. Those set aside 6 bits to encode UUID details, keeping 122 bits of entropy. Since every banana needs its own identifier, subtract the number of bits needed to uniquely represent bananas. What's left will unavoidably be less guess-resistant than client secrets. Other versions of UUID use many more bits for low-entropy purposes.