#Security by obscurity how to#
There are some user interface areas to consider, such as if a user/agent doesn't treat the URL as secret, because it shows content rather than masking characters such as " *".įor comparison, "security by obscurity" means there's a weakness in how the security is built, such that if you saw the source code, or the physical insides of a lock, then you would understand more about how to crack the security. There are some access control areas to consider, such as all the people having the same bearer token, which means there's no way to do finer-grained permissions per-user or per-role or per-attribute. There are implementation areas to consider, such choosing a random number generator with high quality randomness like /dev/urandom. The pattern can tune the security by using more randomness, such as more characters. The security pattern of a URL with a random string is security-equivalent to a pubic username and a random string password, and also equivalent to the security pattern of a bearer token: so long as the URL is shared only with authorized users, it's the same security hardness. Surprisingly, it turns out that using security based on a URL with a random string is /not/ security by obscurity.