Because you want some form of vetting on the names, or a mechanism to
detect when things are compromised, or any number of things.
> Once you go to the trouble of having state information specific to the
> user maintained on the server, i.e. a secret shared between the user
> and the server, you've already decided there's something worth
> protecting. In that case, protecitng the password in transit seems
> obligatory.
Which gets back to the real essence of the argument - that if it costs
more to break the protection you have than you lose if it's broken,
There is no point in going to a more expensive protection mechanism.
> The issue isn't whether the ordinary *user* is competent to mount a
> sniffing attack; the question is what the ordinary *hacker* will do.
The issue isn't about who's going to mount the attack, it's about the
cost of the attack vs. the value of what's being protected. This is,
ultimately, a decision that can only be made by the person who's going
to lose if the protection is broken. Hopefully, they have a good
understanding of the cost of breaking the protection when they make
that decisions.
> I don't know of applications where it makes
> sense to have passwords but doesn't matter if the passwords are
> disclosed to unauthorized people as they're sent over the network. I
> suppose there might be such applications, but I don't know of any.
I can think of such applications. I've even seen things on the web
that look like they would benefit from such an application. It may
even be possible to make money on such an application.
<mike