[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [WEB SECURITY] username & pw in clear-text through SSL considered safe?
- From: Oliver Lavery <oliver@xxxxxxxxxxxxxxxxxxx>
- Subject: Re: [WEB SECURITY] username & pw in clear-text through SSL considered safe?
- Date: Wed, 18 Jun 2008 22:19:28 -0700
--B_3296672368_4193214
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
I=B9d 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=B9t ridiculous. There=B9s a bit of a =8Cthe status quo is good
enough=B9 thing going on in this thread, and that=B9s where we=B9re going a bit
astray in my opinion.
> SSL MITM- There is no such thing as a passive SSL man-in-the-middle, so
> everything everybody has said about modifying the hashing JavaScript in f=
light
> is true. It is also true that the hashed password is a
>=20
That=B9s not entirely true. Not passive, but without substituting certs it=B9s
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 =B3users are dumber than security people=B2 issues.
> =20
> So in the situation with the least amount of SSL security (40-bit export =
DES)
> it is HIGHLY unlikely that MD5ing the user=B9s password in JavaScript will
> increase security in the presence of an attacker that can crack
>=20
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...
> =20
> If you accept weak ciphers in your browser or server, you are in trouble.
> =20
> UseTLSv1 (or 1.1 [4]). Use good cipher suites. Use OTP if possible. Put =
the
> password in a form POST. Don=B9t mess up elsewhere.
>=20
Absolutely!
=20
I=B9ll 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=B9m no big fan of certs, but bandying about cleartext passwords over a
channel that has to efficiently transport large amounts of data (and as suc=
h
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
all.
The fact that the implementation that started this thread is very flawed ha=
s
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=B9s mildly troubling to hear the contrary s=
o
forcefully defended.
Cheers,
~ol
-----
Oliver Lavery
Security Compass
http://www.securitycompass.com/
--B_3296672368_4193214
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
<HTML>
<HEAD>
<TITLE>Re: [WEB SECURITY] username & pw in clear-text through SSL consi=
dered safe?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>I’d like to point out before this gets too out of hand that of cours=
e MD5 hashing a password is a bit silly. In my previous post I wanted to mak=
e 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. <BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><B><I>SSL MITM</I></B><I>- There is no such thin=
g as a passive SSL man-in-the-middle, so everything everybody has said about=
modifying the hashing JavaScript in flight is true. It is also true t=
hat the hashed password is a <BR>
</I><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'>That’s not entirely true. Not passive, bu=
t without substituting certs it’s possible in many cases to trick clie=
nts and servers into using earlier protocol versions and weaker ciphers. So =
if both parties will accept 40bit DES ciphers, Eve, our evesdropper can forc=
e them to do so without cert warnings and such “users are dumber than =
security people” issues.<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'> <BR>
<I>So in the situation with the least amount of SSL security (40-bit export=
DES) it is HIGHLY unlikely that MD5ing the user’s password in JavaScr=
ipt will increase security in the presence of an attacker that can crack <BR=
>
</I><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'>However a SHA256 hash would be different, and t=
here are no widespread vulnerabilities in the protocol that allow an attacke=
r 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 computa=
tionally efficient cipher by a fellow named Caesar...<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'> <BR>
<I>If you accept weak ciphers in your browser or server, you are in trouble=
.<BR>
<BR>
UseTLSv1 (or 1.1 [4]). Use good cipher suites. Use OTP if possible. P=
ut the password in a form POST. Don’t mess up elsewhere.<BR>
</I></SPAN></FONT><I><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT></I></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Ari=
al"><SPAN STYLE=3D'font-size:11pt'>Absolutely!<BR>
<BR>
I’ll add one more here: Use client certificate based authentication f=
or clients wherever feasible. Spend the time to set up a CA for your enterpr=
ise. Get physical tokens of some sort and add another factor. <BR>
<BR>
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 su=
ch has difficult performance vs. data security requirements) is just not the=
best way to do things. The idea of adding more protection for authN credent=
ials than you might apply to a big old blob of XML is not silly at all.<BR>
<BR>
The fact that the implementation that started this thread is very flawed ha=
s 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 cont=
rary so forcefully defended.<BR>
<BR>
Cheers,<BR>
~ol<BR>
-----<BR>
Oliver Lavery<BR>
Security Compass<BR>
<a href=3D"http://www.securitycompass.com/";>http://www.securitycompass.com/</=
a><BR>
</SPAN></FONT>
</BODY>
</HTML>
--B_3296672368_4193214--
Brought to you by http://www.webappsec.org
Search this site
|