Sam Varshavchik wrote:
That response doesn't make any sense. What machine I'm accessing from
or the method of access has nothing to do with the password showing up
in the URL bar.
Yes it does. If these precautions are taken, what shows up in the URL bar
cannot be intercepted over the network.
The network is not where the danger lies. The password in the URL will
end up both in the server log files, and in the browser cache - neither
of these are secured very well (or at all) in most installations.
I'm pretty sure it's sufficient to change the form so it is submitted via
POST, instead of a get.
This will fix the problem, yes.
I have a different philosophy: focus all the attention, and the efforts, on
preventing root exploits from happening in the first place, instead of
accepting them as inevitable, and working towards mitigating the damages.
The real solution is to focus on both of these at the same time.
So far, my strategy is working.
You're fighting the laws of statistics. The harder you try to minimise
root exploits, the smaller the risk of them occuring. But - as time
passes the risk will accumulate to the point where at least one exploit
is inevitable. I'd rather that root exploit be a nobody exploit (or
similarly restricted exploit) when it finally does happen.
Root exploits happen eventually to the most careful of programmers.
Regards,
Graham
6 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Re: courier-users...
