4 ms·
Security by obscurity and a perfect example of failure to restrict URL access: http://www.troyhunt.com/2011/08/owasp-top-10-for-net-developers-part-8.html http:
by troyhunt 15y ago
Security by obscurity and a perfect example of failure to restrict URL access: http://www.troyhunt.com/2011/08/owasp-top-10-for-net-developers-part-8.html http://www.troyhunt.com/2011/08/owasp-top-10-for-net-develop...
These URLs are exposed in all sorts of places; browser history, proxy servers, web server logs and ISP gateways to name just a few. Never put secrets in URLs and expect it to remain secret.
Here's an objective suggestion - put the proposal over on stackoverflow.com and see what response you get.
- gmac 15y agoNot that I'm advocating this as a good authentication solution, but the worst sorts of exposures you list (i.e. the ones that aren't restricted to the authicatee's device or the authenticator's server) don't apply if you use SSL. Which of course you do.
- cubicle67 15y agoFirst, it's ssl only. Second, the alternative (which I'm trying to avoid and where this idea came from) is a user being prompted for a password and responding something like "er, um... Password123" or just using the same password they use for everything else The idea was that this may give users a bit more time to think about passwords, and possibly be more secure than the usual passwords. Stating the idea here is giving me some good things to consider
- mattgreenrocks 15y agoWhy not use OAuth or something similar so you deal with auth tokens, rather than passwords?
- cubicle67 15y agoBecause I'm dealing with exactly the type of users who think 1234 is a great password.
- deleted 15y ago[deleted]