[WEB SECURITY] username & pw in clear-text through SSL considered safe?
oliver at securitycompass.com
Thu Jun 19 01:19:28 EDT 2008
I¹d like to point out before this gets too out of hand that of course MD5
hashing a password is a bit silly. In my previous post I wanted to make it
clear that it wasn¹t ridiculous. There¹s a bit of a the status quo is good
enough¹ thing going on in this thread, and that¹s where we¹re going a bit
astray in my opinion.
> SSL MITM- There is no such thing as a passive SSL man-in-the-middle, so
> is true. It is also true that the hashed password is a
That¹s not entirely true. Not passive, but without substituting certs it¹s
possible in many cases to trick clients and servers into using earlier
protocol versions and weaker ciphers. So if both parties will accept 40bit
DES ciphers, Eve, our evesdropper can force them to do so without cert
warnings and such ³users are dumber than security people² issues.
> So in the situation with the least amount of SSL security (40-bit export DES)
> increase security in the presence of an attacker that can crack
However a SHA256 hash would be different, and there are no widespread
vulnerabilities in the protocol that allow an attacker to pick your hashing
algorithm or simply remove it. Nobody should use MD5 or DES anymore, period.
If you are than please consider an even more computationally efficient
cipher by a fellow named Caesar...
> If you accept weak ciphers in your browser or server, you are in trouble.
> UseTLSv1 (or 1.1 ). Use good cipher suites. Use OTP if possible. Put the
> password in a form POST. Don¹t mess up elsewhere.
I¹ll add one more here: Use client certificate based authentication for
clients wherever feasible. Spend the time to set up a CA for your
enterprise. Get physical tokens of some sort and add another factor.
I¹m no big fan of certs, but bandying about cleartext passwords over a
channel that has to efficiently transport large amounts of data (and as such
has difficult performance vs. data security requirements) is just not the
best way to do things. The idea of adding more protection for authN
credentials than you might apply to a big old blob of XML is not silly at
The fact that the implementation that started this thread is very flawed has
turned it into a bit of a straw man argument... the implementation is bad,
but the idea that HTTP over SSL may not be all anyone ever needs to protect
authN data has a lot of merit. It¹s mildly troubling to hear the contrary so
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the websecurity