[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 13:17:06 -0700
--B_3296639827_2895479
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Which is, incidentally, why a few comments in this thread about hashing
schemes being just a layer of obfuscation are not completely true.
It=B9s a good point that SSL can be cracked, and in fact with many servers
configured to accept low-strength ciphers, it=B9s not really as impossible as
it may sound (Lots of servers are configured to still support 40 bit
=8Cexportable=B9 DES! Eeek!).
When talking about protecting the password within the SSL protocol stream,
we tend to think only in terms of MiM attacks where the attacker controls
the keys and has full control of the stream. This is a more difficult attac=
k
then simply being able to intercept the encrypted traffic, possibly in
conjunction with an SSL cipher/protocol downgrade attack.
There is a non-zero risk of breaking the key to decrypt intercepted SSL as
you point out, and if cleartext passwords are used then the attacker gains
the password in this case, not just the rest of the plaintext protocol
stream. While hashing alone doesn=B9t solve the problem (as the hash becomes
equivalent to the password) using a nonce does improve things in the case o=
f
a break, because the hash can not be replayed. From what I understand the
hash itself is difficult to break in such a scheme as well, because it need=
s
to be reversed; simply finding a hash collision does not yield the original
password.=20
Also, it isn=B9t relevant that the attacker knows the nonce from the decrypte=
d
protocol stream since it=B9s just a one-time value used as input to a hashing
algorithm.=20
Not to flog a dead horse, but I didn=B9t want to see this thread conclude wit=
h
information that is slightly misleading... There are definitely hashing
schemes that add to the security of a password in transit.
Naturally the whole web should disable SSLv2 and weak ciphers as well.
Cheers,
~ol
------
Oliver Lavery
Security Compass
http://www.securitycompass.com/
On 18/06/08 10:49 AM, "Ivan Ristic" <ivan.ristic@gmail.com> wrote:
> On Tue, Jun 17, 2008 at 11:27 PM, Martin O'Neal
> <martin.oneal@corsaire.com> wrote:
>> >
>>> >> I'm not sure if hashing the password
>>> >> on the client side would be best practice
>>> >> (anyone have a strong opinion?) but it
>>> >> seems effective.
>> >
>> > The problem is that it is not effective, just cosmetic. It doesn't bu=
y
>> > you anything (other than a false sense of security).
>> >
>> > If someone has compromised your SSL, they can change whatever you put
>> > inside it. In this example, all an attacker has to do is amend the
>> > javascript as it goes past and make it send the cleartext auth.
>=20
> I think most people tend to think about SSL as if the protection it is
> providing is permanent, that, if you're not compromised initially
> (e.g. with an MITM attack or an application vulnerability) then you
> are never going to be compromised. This is not strictly true, although
> it is virtually true for almost everyone. An encrypted SSL session can
> be stored, kept indefinitely, and broken... eventually. At that point,
> whatever was in the session, including the password, will be known to
> the attacker. I accept that this is a stretch (and a really big one),
> but purely from that point it's better to not have the password in
> clear. Of course, people that are concerned with this sort of problem
> should really look into using multi-factor authentication.
>=20
> For the same reason, people need to think in terms for how long
> information needs to stay protected when choosing SSL key sizes and
> ciphers.
>=20
>=20
>> > Martin...
>> >
>> >
>> >
>> >=20
>> ------------------------------------------------------------------------=
----
>> > Join us on IRC: irc.freenode.net #webappsec
>> >
>> > Have a question? Search The Web Security Mailing List Archives:
>> > http://www.webappsec.org/lists/websecurity/
>> >
>> > Subscribe via RSS:
>> > http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>> >
>> > Join WASC on LinkedIn
>> > http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>=20
> --
> Ivan Ristic
>=20
> -------------------------------------------------------------------------=
---
> Join us on IRC: irc.freenode.net #webappsec
>=20
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/
>=20
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>=20
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>=20
>=20
--B_3296639827_2895479
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=
'>Which is, incidentally, why a few comments in this thread about hashing sc=
hemes being just a layer of obfuscation are not completely true.<BR>
<BR>
It’s a good point that SSL can be cracked, and in fact with many serv=
ers configured to accept low-strength ciphers, it’s not really as impo=
ssible as it may sound (Lots of servers are configured to still support 40 b=
it ‘exportable’ DES! Eeek!).<BR>
<BR>
When talking about protecting the password within the SSL protocol stream, =
we tend to think only in terms of MiM attacks where the attacker controls th=
e keys and has full control of the stream. This is a more difficult attack t=
hen simply being able to intercept the encrypted traffic, possibly in conjun=
ction with an SSL cipher/protocol downgrade attack.<BR>
<BR>
There is a non-zero risk of breaking the key to decrypt intercepted SSL as =
you point out, and if cleartext passwords are used then the attacker gains t=
he password in this case, not just the rest of the plaintext protocol stream=
. While hashing alone doesn’t solve the problem (as the hash becomes e=
quivalent to the password) using a nonce does improve things in the case of =
a break, because the hash can not be replayed. From what I understand the ha=
sh itself is difficult to break in such a scheme as well, because it needs t=
o be reversed; simply finding a hash collision does not yield the original p=
assword. <BR>
<BR>
Also, it isn’t relevant that the attacker knows the nonce from the de=
crypted protocol stream since it’s just a one-time value used as input=
to a hashing algorithm. <BR>
<BR>
Not to flog a dead horse, but I didn’t want to see this thread conclu=
de with information that is slightly misleading... There are definitely hash=
ing schemes that add to the security of a password in transit.<BR>
<BR>
Naturally the whole web should disable SSLv2 and weak ciphers as well.<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>
<BR>
<BR>
<BR>
On 18/06/08 10:49 AM, "Ivan Ristic" <<a href=3D"ivan.ristic@gmai=
l.com">ivan.ristic@gmail.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>On Tue, Jun 17, 2008 at 11:27 PM, Martin O'Neal<=
BR>
<<a href=3D"martin.oneal@corsaire.com">martin.oneal@corsaire.com</a>> w=
rote:<BR>
><BR>
>> I'm not sure if hashing the password<BR>
>> on the client side would be best practice<BR>
>> (anyone have a strong opinion?) but it<BR>
>> seems effective.<BR>
><BR>
> The problem is that it is not effective, just cosmetic. It doesn=
't buy<BR>
> you anything (other than a false sense of security).<BR>
><BR>
> If someone has compromised your SSL, they can change whatever you put<=
BR>
> inside it. In this example, all an attacker has to do is amend t=
he<BR>
> javascript as it goes past and make it send the cleartext auth.<BR>
<BR>
I think most people tend to think about SSL as if the protection it is<BR>
providing is permanent, that, if you're not compromised initially<BR>
(e.g. with an MITM attack or an application vulnerability) then you<BR>
are never going to be compromised. This is not strictly true, although<BR>
it is virtually true for almost everyone. An encrypted SSL session can<BR>
be stored, kept indefinitely, and broken... eventually. At that point,<BR>
whatever was in the session, including the password, will be known to<BR>
the attacker. I accept that this is a stretch (and a really big one),<BR>
but purely from that point it's better to not have the password in<BR>
clear. Of course, people that are concerned with this sort of problem<BR>
should really look into using multi-factor authentication.<BR>
<BR>
For the same reason, people need to think in terms for how long<BR>
information needs to stay protected when choosing SSL key sizes and<BR>
ciphers.<BR>
<BR>
<BR>
> Martin...<BR>
><BR>
><BR>
><BR>
> ----------------------------------------------------------------------=
------<BR>
> Join us on IRC: irc.freenode.net #webappsec<BR>
><BR>
> Have a question? Search The Web Security Mailing List Archives:<BR>
> <a href=3D"http://www.webappsec.org/lists/websecurity/";>http://www.webap=
psec.org/lists/websecurity/</a><BR>
><BR>
> Subscribe via RSS:<BR>
> <a href=3D"http://www.webappsec.org/rss/websecurity.rss";>http://www.weba=
ppsec.org/rss/websecurity.rss</a> [RSS Feed]<BR>
><BR>
> Join WASC on LinkedIn<BR>
> <a href=3D"http://www.linkedin.com/e/gis/83336/4B20E4374DBA";>http://www.=
linkedin.com/e/gis/83336/4B20E4374DBA</a><BR>
<BR>
--<BR>
Ivan Ristic<BR>
<BR>
---------------------------------------------------------------------------=
-<BR>
Join us on IRC: irc.freenode.net #webappsec<BR>
<BR>
Have a question? Search The Web Security Mailing List Archives:<BR>
<a href=3D"http://www.webappsec.org/lists/websecurity/";>http://www.webappsec.=
org/lists/websecurity/</a><BR>
<BR>
Subscribe via RSS:<BR>
<a href=3D"http://www.webappsec.org/rss/websecurity.rss";>http://www.webappsec=
.org/rss/websecurity.rss</a> [RSS Feed]<BR>
<BR>
Join WASC on LinkedIn<BR>
<a href=3D"http://www.linkedin.com/e/gis/83336/4B20E4374DBA";>http://www.linke=
din.com/e/gis/83336/4B20E4374DBA</a><BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>
--B_3296639827_2895479--
Brought to you by http://www.webappsec.org
Search this site
|