[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: Alex Stamos <alex@xxxxxxxxxxxxxxxx>
- Subject: RE: [WEB SECURITY] username & pw in clear-text through SSL considered safe?
- Date: Wed, 18 Jun 2008 15:28:04 -0700
--_000_7E3B942D6F9AE64EA28CE80B7283C1EC17E86CC37Fexch01isecpar_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
The hashing of a password in JavaScript with MD5, with or without a salt/no=
nce, adds very little security in any failure mode of the SSL connection. =
Let's look at two scenarios:
SSL MITM- There is no such thing as a passive SSL man-in-the-middle, so eve=
rything everybody has said about modifying the hashing JavaScript in flight=
is true. It is also true that the hashed password is a password equivalen=
t. It is also true that the cookie returned by the application is a passwo=
rd equivalent for the duration of the session. There is no benefit to the =
hashing in this situation.
SSL Decryption- Let's assume the best-case scenario for an attacker: a webs=
ite and client are negotiating SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, which is =
unlikely these days without but the basis of this worst-case analysis[1]. =
The fastest attack will be a brute-force of the 40-bit (effective) DES assu=
ming a known-plaintext as a decryption oracle in the first block.
Years ago people demonstrated the power of attacking DES with dedicated ASI=
Cs or FPGAs, but let's assume our attacker is lazy and wants to use somethi=
ng sitting in his office.
On the Mac Pro sitting in our lab I get ~2M keys/sec per core cracking DES.=
That means I'll need roughly 38 hours to brute-force the 40-bit key on a =
four core machine. Finding this key will allow the attacker to decode the =
entirety of the SSL connection, assuming there was no re-negotiation of the=
key.
At this point the attacker has the entire conversation, including the hash,=
the cookie, and the person's sensitive banking information. Perhaps the a=
ttacker wants more because the password was hashed with a salt/nonce and th=
e hash is no longer a password equivalent.
The mdcrack guys claim 42M MD5 guesses/sec on a four core Xeon[2]. I didn'=
t have a chance to verify that.
For a "perfect" 8-character password (~52 bits of entropy) brute-forcing th=
e MD5 hash in software is not feasible. Normal users do not pick perfect p=
asswords, and a NIST study determined that a human chosen 8-character passw=
ord will contain 18-30 bits of entropy depending on the password rules enfo=
rced.[3] That means we would need between .006 and 25 seconds to guess a hu=
man-created 8-character password. Even assuming 40 bits of password entrop=
y, due to the speed of MD5 we would only need ~7 hours to crack the passwor=
d with the same machine we used to crack DES.
So in the situation with the least amount of SSL security (40-bit export DE=
S) it is HIGHLY unlikely that MD5ing the user's password in JavaScript will=
increase security in the presence of an attacker that can crack EXPORT SSL=
(basically anybody with a computer from 2007 and two days). There are sit=
uations where password hashing is smart, but until JavaScript has a native-=
code 1000-round PKCS #5 function, I wouldn't recommend it.
If you accept weak ciphers in your browser or server, you are in trouble.
UseTLSv1 (or 1.1 [4]). Use good cipher suites. Use OTP if possible. Put th=
e password in a form POST. Don't mess up elsewhere.
-Alex
[1] Attacking RC4 with its weak key scheduling algorithm would probably be =
faster but this is a good example.
[2] http://c3rb3r.openwall.net/mdcrack/
[3] http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
[4] http://www.root.org/talks/TLS_Flaw20080110.pdf
From: Oliver Lavery [mailto:oliver@securitycompass.com]
Sent: Wednesday, June 18, 2008 1:17 PM
To: Ivan Ristic; Martin O'Neal
Cc: Chris Varenhorst; wilke rodriquez; Rohit Lists; websecurity@webappsec.o=
rg
Subject: Re: [WEB SECURITY] username & pw in clear-text through SSL conside=
red safe?
Which is, incidentally, why a few comments in this thread about hashing sch=
emes being just a layer of obfuscation are not completely true.
It's a good point that SSL can be cracked, and in fact with many servers co=
nfigured to accept low-strength ciphers, it's not really as impossible as i=
t may sound (Lots of servers are configured to still support 40 bit 'export=
able' 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 t=
he keys and has full control of the stream. This is a more difficult attack=
then simply being able to intercept the encrypted traffic, possibly in con=
junction 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 stre=
am. While hashing alone doesn't solve the problem (as the hash becomes equi=
valent 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 has=
h 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 =
password.
Also, it isn't relevant that the attacker knows the nonce from the decrypte=
d protocol stream since it's just a one-time value used as input to a hashi=
ng algorithm.
Not to flog a dead horse, but I didn't want to see this thread conclude wit=
h information that is slightly misleading... There are definitely hashing s=
chemes 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 buy
> 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.
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.
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.
> Martin...
>
>
>
> -------------------------------------------------------------------------=
---
> 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
--
Ivan Ristic
---------------------------------------------------------------------------=
-
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
--_000_7E3B942D6F9AE64EA28CE80B7283C1EC17E86CC37Fexch01isecpar_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml"; xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<title>Re: [WEB SECURITY] username & pw in clear-text through SSL
considered safe?</title>
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3DEN-US link=3Dblue vlink=3Dpurple>
<div class=3DSection1>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>The hashing of a password in JavaScript with MD5, with or
without a salt/nonce, adds very little security in any failure mode of the =
SSL
connection. Let’s look at two scenarios:<o:p></o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><b><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif";
color:#1F497D'>SSL MITM</span></b><span style=3D'font-size:11.0pt;font-fami=
ly:
"Calibri","sans-serif";color:#1F497D'>- There is no such thing as a passive=
SSL
man-in-the-middle, so everything everybody has said about modifying the has=
hing
JavaScript in flight is true. It is also true that the hashed passwor=
d is
a password equivalent. It is also true that the cookie returned by th=
e
application is a password equivalent for the duration of the session.
There is no benefit to the hashing in this situation. <o:p></o:p></sp=
an></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><b><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif";
color:#1F497D'>SSL Decryption</span></b><span style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>- Let’s assume the
best-case scenario for an attacker: a website and client are negotiating
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, which is unlikely these days without but=
the
basis of this worst-case analysis[1]. The fastest attack will be a
brute-force of the 40-bit (effective) DES assuming a known-plaintext as a
decryption oracle in the first block. <o:p></o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Years ago people demonstrated the power of attacking DES wit=
h
dedicated ASICs or FPGAs, but let’s assume our attacker is lazy and w=
ants
to use something sitting in his office. <o:p></o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>On the Mac Pro sitting in our lab I get ~2M keys/sec per cor=
e
cracking DES. That means I’ll need roughly 38 hours to brute-fo=
rce
the 40-bit key on a four core machine. Finding this key will allow th=
e
attacker to decode the entirety of the SSL connection, assuming there was n=
o re-negotiation
of the key.<o:p></o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>At this point the attacker has the entire conversation,
including the hash, the cookie, and the person’s sensitive banking
information. Perhaps the attacker wants more because the password was=
hashed
with a salt/nonce and the hash is no longer a password equivalent.<o:p></o:=
p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>The mdcrack guys claim 42M MD5 guesses/sec on a four core Xe=
on[2].
I didn’t have a chance to verify that.<o:p></o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>For a “perfect” 8-character password (~52 bits o=
f
entropy) brute-forcing the MD5 hash in software is not feasible. Norm=
al
users do not pick perfect passwords, and a NIST study determined that a hum=
an
chosen 8-character password will contain 18-30 bits of entropy depending on=
the
password rules enforced.[3] That means we would need between .006 and 25
seconds to guess a human-created 8-character password. Even assuming =
40
bits of password entropy, due to the speed of MD5 we would only need ~7 hou=
rs
to crack the password with the same machine we used to crack DES.<o:p></o:p=
></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>So in the situation with the least amount of SSL security
(40-bit export DES) it is HIGHLY unlikely that MD5ing the user’s pass=
word
in JavaScript will increase security in the presence of an attacker that ca=
n
crack EXPORT SSL (basically anybody with a computer from 2007 and two
days). There are situations where password hashing is smart, but unti=
l
JavaScript has a native-code 1000-round PKCS #5 function, I wouldn’t
recommend it.<o:p></o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>If you accept weak ciphers in your browser or server, you ar=
e in
trouble.<o:p></o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>UseTLSv1 (or 1.1 [4]). Use good cipher suites. Use OTP=
if
possible. Put the password in a form POST. Don’t mess up elsewh=
ere.<o:p></o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'> -Alex<o:p></o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>[1] Attacking RC4 with its weak key scheduling algorithm wou=
ld
probably be faster but this is a good example. <o:p></o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>[2] <a href=3D"http://c3rb3r.openwall.net/mdcrack/";>http://c=
3rb3r.openwall.net/mdcrack/</a><o:p></o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>[3] <a
href=3D"http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pd=
f">http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf</a>=
<o:p></o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>[4] <a href=3D"http://www.root.org/talks/TLS_Flaw20080110.pd=
f">http://www.root.org/talks/TLS_Flaw20080110.pdf</a><o:p></o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>
<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Oliver Lavery
[mailto:oliver@securitycompass.com] <br>
<b>Sent:</b> Wednesday, June 18, 2008 1:17 PM<br>
<b>To:</b> Ivan Ristic; Martin O'Neal<br>
<b>Cc:</b> Chris Varenhorst; wilke rodriquez; Rohit Lists;
websecurity@webappsec.org<br>
<b>Subject:</b> Re: [WEB SECURITY] username & pw in clear-text through =
SSL
considered safe?<o:p></o:p></span></p>
</div>
</div>
<p class=3DMsoNormal><o:p> </o:p></p>
<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span style=3D'font-siz=
e:11.0pt;
font-family:"Calibri","sans-serif"'>Which is, incidentally, why a few comme=
nts
in this thread about hashing schemes 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 impossi=
ble
as it may sound (Lots of servers are configured to still support 40 bit
‘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 the =
keys
and has full control of the stream. This is a more difficult attack then si=
mply
being able to intercept the encrypted traffic, possibly in conjunction 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 the
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 equivale=
nt
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 hash itsel=
f is
difficult to break in such a scheme as well, because it needs to be reverse=
d;
simply finding a hash collision does not yield the original password. <br>
<br>
Also, it isn’t relevant that the attacker knows the nonce from the
decrypted protocol stream since it’s just a one-time value used as in=
put
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 hashin=
g
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@gmail.com">ivan.ristic@gmail.com</a>> wrote:</span><=
o:p></o:p></p>
<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span style=3D'font-siz=
e:11.0pt;
font-family:"Calibri","sans-serif"'>On Tue, Jun 17, 2008 at 11:27 PM, Marti=
n
O'Neal<br>
<<a href=3D"martin.oneal@corsaire.com">martin.oneal@corsaire.com</a>>
wrote:<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.web=
appsec.org/lists/websecurity/</a><br>
><br>
> Subscribe via RSS:<br>
> <a href=3D"http://www.webappsec.org/rss/websecurity.rss";>http://www.we=
bappsec.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://ww=
w.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.webappse=
c.org/lists/websecurity/</a><br>
<br>
Subscribe via RSS:<br>
<a href=3D"http://www.webappsec.org/rss/websecurity.rss";>http://www.webapps=
ec.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.lin=
kedin.com/e/gis/83336/4B20E4374DBA</a><br>
<br>
</span><o:p></o:p></p>
</div>
</body>
</html>
--_000_7E3B942D6F9AE64EA28CE80B7283C1EC17E86CC37Fexch01isecpar_--
Brought to you by http://www.webappsec.org
Search this site
|