note
FoxtrotUniform
<ul><i>
<p>Unfortunately, storing the crypted version of the
password on the server means that the client has to send
the password to the server in plaintext. Either you hide
that with SSL, or you accept the fact that you have no real
security.</p>
<p>If you try to protect the password in transit by using
something like HTTP digest authentication, then you have to
store the password (or some equivalent secret information)
in plaintext on the server. Which is the bigger
vulnerability?</p>
</i></ul>
<p>Some excellent points, [no_slogan]. It's kind of
depressing that the current state of the art, as far as
anything common enough to be useful goes, relies so much
on plaintext passwords. (Although you might be able to
get the client to hash the password before sending it over
the wire, using a browser plugin of some sort. Provided
that you trust the plugin.)</p>
<p>Is there a better way of doing user authentication for
sites like PerlMonks out there that doesn't rely on
pie-in-the-sky technology? (Preferably something that
doesn't involve shared secrets, which IMHO are just too
much trouble.) Having the client hash the password before
sending it over the wire is a start, but doesn't help much
if the server isn't who the client thinks it is, since the
attacker can just play back the password hash at the real
server.</p>
<p>I'd look up some ideas, but my copy of Applied Crypto
is at home, and I'm not. Anyone else?</p>
<p><tt>-- <br>
:wq</tt></p>
153507
153622