Why? Done properly, a secure URL should be as long and contain as much entropy as a strong password.
Are all systems which depend on someone not guessing your strong password wrong? Are practically all encryption schemes wrong?
Why? Done properly, a secure URL should be as long and contain as much entropy as a strong password.
Are all systems which depend on someone not guessing your strong password wrong? Are practically all encryption schemes wrong?
I'm not saying that it's necessarily wrong to use a long URL as security; sometimes the problem constraint means that is the only way to do it. I've done it on rare occasion. But I also made sure that management knew there was a risk here.
The latter is up to server design, the former is an interesting point.
Browsers are unlikely to cache get parameters, but these things might end up in history etc..
No, but if your security system has a password and only one account shared by everyone where the password is shared as plain text (typically just emailed from person to person) without any sort of user access logging then it's got major problems.
With just a URL you have no idea who has access and the only way of revoking access to anyone is to permanently move the resource and then get back in contact with everyone who should have access by sending the new "password" around.
> Are practically all encryption schemes wrong?
An encryption scheme that involves the users sharing the only password through far less secure channels?
The path is exactly as secure as authorization headers. Network logs will not show the path of SSL requests (it's encrypted).
If you give your link to a dodgy search engine, you've lost.