That means using https, not logging accesses, or returning the secret in other api calls. You'll need to ensure that the secret is not leaked. Also, password reset links are basically this, except they are (hopefully) only usable once. It's long enough that you could never feasibly guess that link. there are many systems that actually work like this already.įor example, in google docs, you can create a link that anyone with that link can edit the document. This is actually a pretty reasonable idea IF you use a large, and randomly generated url. I'm planning to use it in an app where I feel people will value simplicity above security. I don't see that this is less secure than the average password when used with a long secret URL (64 characters anyone? 2000 - domain_length?), in combination with a tar-pit. In contrast here you're being open about implementation and design. It's not security through obscurity - that's a misunderstanding of the normal use of the phrase. If people access your secret URL via HTTP, warn them and immediately change it Design for that, and use it appropriately - like the Google docs "Anyone with this link" sharing method.ĭoesn't set referrer headers if they click a HTTP link It will be unintentionally shared or posted somewhere Google will index it. The biggest security hole would be the people using it. I'd say if you're careful they can be secure. Never practice security using obscurity as the only safeguard. Recommendation: Use both a "secret" URL and a very strong user name/password combination. This, in turn, makes them a better choice than a simple obscured URL. In other words, passwords are layered and are practicing security through other means in addition to obscurity. Passwords may be obscured information by definition, but the extra efforts, precautions, and safeguards taken around passwords adds a level of security on top of it all. Secret URLs are only practicing security through obscurity. ![]() The URL exists in plain text on the server somewhere, whether as real directory/files or as a rewrite (however, a rewrite could be down at a much higher level).Įverything else that Clark has mentioned in his answer. If the secret URL is compromised, you have to change it and notify anyone using it. URLs are shown in the browser window and can be privy to wandering eyes. mode, the URL will be stored in your local history/cache. Unless used in "Incognito", "Private", etc. Good password systems don't store them in plain-text on the filesystem. Passwords can be changed in the case of a breach without the need to change the entry-point into the system. User name and password combinations are not statically shown on the screen, nor stored anywhere in the browser (unless you chose to have your browser "save" your login credentials). Making a password out of a series of random words makes the password very strong and very hard to guess or brute force.Ī password has to be coupled with a user name, which also can increase security if the user name is not common. A secret URL and a password do share one similar characteristic: they are known to one or more specific person/people. I would highly disagree with that comparison. I'd like to expand on this, as I see some argument is still being made that a secret URL is no different than a password. ![]() Original Answer: Security through obscurity is something that should never be practiced. But when using common web browsers, web servers and web frameworks, hard-to-guess URLs should not be relied upon unless no other option exists (and even then you should consider carefully). In a highly controlled environment, hard-to-guess URLs can be secure. HTTPS can protect some of these, but not all of them (items marked with a * are not protected against by using HTTPS.) In proxy and layer 7 firewall access logs. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |