[WEB SECURITY] username & pw in clear-text through SSL considered safe?

[Arian J. Evans]

That is a very nice summary, Alex. I am surprised
I disagree with most of the usual suspects on this thread.

Your technical bits are excellent, and I think spot on.

However -- I would like to pull this back up out of
the technical weeds a bit:.

All this notion of "layered password protection", even
challenge-response mechanisms, is total nonsense.

By this I mean: "total nonsense today in terms of value
given what we can implement today in the browser".

We need separate data and control channels. That
is worth discussing. Without that every scenario
described still passes the key with the message.

Pragmatically speaking -- I have yet in my career
to find a web application scenario (including RIA)
using password or token hashing/obfuscation
mechanisms driven by the browser...
that I could not reverse. In a few cases this includes
even server-side implementations, but I digress.

Considering I barely completed compensatory math,
this means defeating these solutions is trivial.

Long and short --

(1) The whole concept of adding obfuscation or
cipher protection whilst intermingling the data
and control channel is corrupt.

(2) The discussion, and usual notions of, "defense
in depth" on web assets is usually filled with mindless
platitudes about "layers" and "best practices" that
provide little if any protection for the actual threat landscape.

<insert:subjective_debate>

I am completely cynical to this discussion as I've
watched companies waste significant amounts of
time and money for over a decade on crypto and
obfuscation layers in their webapps that do nothing
for them at the end of the day.

Ivan is correct that without specific context including
threat landscape and attack surface, it is hard to
have a functional debate. Alex did well by laying
out an implied one is his response.

The next thread should probably delve into the
completely subjective and debatable:

+ What is the *real* threat landscape?

+ Who has real data and is willing to share?

+ What are the cost/benefit models to explore
the *potential* value of implementing these
"failure proofing" and "future-proofing" measures?

Otherwise we're wasting each other's time by
debating the merits of something we know is
of limited value, but that no one in the discussion
has data with which to measure even that.

Also --

How do we get the folks tracking monitization to the
table in our webappsec circles?:

http://www.isightpartners.com/threatscape.html

This is the kind of data that would be useful to
evaluate some of the propositions in this thread
in terms of their value to people today.

Don't pass keys with messages.

Fix all the broken syntax and weak semantics
in your software FIRST....before you go layering
on more complexity to "protect it"

-- 
-- 
Arian J. Evans.

When in doubt -- give 'er more gas. -- Proficient Motorcycling 101



On Thu, Jun 19, 2008 at 9:25 AM, Alex Stamos <alex at isecpartners.com> wrote:
> Oliver-
>
> I don't think anybody on this thread is arguing that there are not better ways to authenticate web applications than passwords in forms.  I have heard nobody argue against research into new methods or the use of existing non-password mechanisms.
>
> So to wrap up my thoughts on the topic, I'm gonna move to the intellectually lazy Q&A style, then I will bow out of this conversation, since it seems to be getting unnecessarily personal.
>
>
> ---
>
> Our imaginary web developer and security consultant, sitting on the banks of a fake corporate pond, skipping rocks and chatting about authentication technologies:
>
> Q: I think passwords are a crappy way of authenticating web applications.  What do you think?
>
> A: I agree!
>
> Q: So then we agree that it's better to hash the password client-side with JavaScript, using a per-session nonce/salt provided by the server?
>
> A: Um, no.  [Alex rehashes quantitative arguments from last email].  I don't think that provides meaningful protection in any failure mode of the SSL/TLS connection.
>
> Q: Ah, but your argument is based upon MD5!  It's more secure with SHA-1!
>
> A: Not really.  SHA-1 is also pretty darn fast in software and blazingly fast in hardware.  That's not coincidental; speed is one of the design goals of a one-way hash algorithm.  Their strength is not supposed to be based on their difficulty to calculate.
>
> The problem here is that passwords are low-entropy.  Feeding a 30-bit password into a 160-bit hash algorithm doesn't make it any more entropic, just "whiter".  Using a cryptographic hash function to create a password equivalent is not the correct solution. [1]
>
> Q: What about defense in depth? Isn't it better to do something, anything to make it harder to retrieve the password?
>
> A: Eh, this is where it becomes a judgment call.  As a security practitioner, I should not recommend security mechanisms that may warp my client's sense of risk without providing meaningful protections.  This is why snake oil fixes are so bad; not just because they don't work, but because a team that believes they work is likely to make incorrect decisions in the future based upon that "protection".  I wouldn't call hashing a password in JavaScript total snake oil, but it's close.
>
> Another problem here is that this is a (weak) protection against an attack scenario I have never actually seen used against a real client.  On the list of ways web app identities are stolen in the real world, "decryption of an EXPORT cipher strength SSL connection" is down around #153, between "I put my password on my license plate" and "My two year old told my password to his day care provider".
>
> MITM attacks against SSL connections that trick people into accepting the wrong cert are a real problem, but we have not been discussing protections that solve that issue.  Certainly password hashing in JS does not. If I am going to recommend a way of strengthening authentication, it needs to address the real authentication risks websites are facing: plaintext communication (meaning no SSL), bad cookies, phishing, malware, CSRF and XSS.
>
> Q: So you think plaintext passwords sent down TLS is the best we can do?
>
> A: No, absolutely not!  We are stuck in the human-remembered password bog due to how cheap and easy it is to use passwords to authenticate people, not because there is a lack of other options.  There are ways to build secure authentication mechanisms on top of even weak passwords, and as much as it pains me to give Stanford a shout-out, SRP is a good example.[2] A lot of these secure password protocols eschew the hash paradigm for zero-knowledge proofs and avoid many of the mistakes of protocols like NTLM.
>
> While better protocols can be implemented in JavaScript, they are useless unless they are integrated with the browser or OS in a way that changes a users behavior when logging in.  SRP in JS would be useless in preventing phishing or active MITM attacks, because somebody is still typing their password into a HTML form.  That's why consumer-usable systems in the OS like CardSpace are so exciting, although they are rarely utilized in the field.
>
> Password tokens get rid of some of these issues, and the economics of them is getting to the point where companies like PayPal can deploy them to clients.  Client certificates are great for authentication, but are very difficult to manage, even in corporate environments.
>
> Anyway, there's a lot of room for startups or the browser gods to make some innovative fixes here.
>
> Q: Do these arguments hold for system to system communication that happens to use HTTP(S)?
>
> A: No. If you have something other than a web browser as a client then there should be many other options, including a number of WS-* mechanisms and transport-layer mechanisms like client certificates.   If you are building a RIA application for example, you should explore the alternative authentication mechanisms instead of plaintext auth or even try to import an implementation of something like SRP.  However, if you control the software on both sides there is no excuse for ever allowing a certificate mismatch lead to a compromised SSL session.  Make sure to set up your SSL context correctly!
>
> ---
>
> That's enough for me.  Somebody else can have the last word before Bob inevitably shuts down the thread.
>
>    -Alex
>
>
>
> [1] There are real authentication protocols that use one-way hashes as a building block, but these are generally still vulnerable to offline dictionary attacks.  Several years ago my colleague, Jesse Burns, described some of these weaknesses in a popular hash-based authentication protocol, NTLM: http://www.isecpartners.com/documents/NTLM_Unsafe.pdf
>
> [2] http://srp.stanford.edu/
>
>
>
>
> ----
>
> From: Oliver Lavery [mailto:oliver at securitycompass.com]
> Sent: Thursday, June 19, 2008 12:22 AM
> To: Martin O'Neal; Alex Stamos; websecurity at webappsec.org
> Subject: Re: [WEB SECURITY] username & pw in clear-text through SSL considered safe?
>
> Martin,
>
> That really isn't my point, and this is just flamebate.
>
> My point is that sending cleartext passwords over sorta-authenticated SSL is far from an ideal solution, and it's worth being open to alternatives. I've suggested a few.
>
> James Landis's point that challenge response protocols require secure storage is a very good one; in the world of webappsec and SQL injection, this isn't a good tradeoff. Even ignoring the security of the storage, it's far from an ideal solution, it just doesn't suck quite as badly.
>
> Web application security is dreadful, SSL is not a magic crypto bullet, and it's an interesting subject to discuss. LOLs and strawmen aside, the web is broken and it's worth thinking about how it could be fixed.
>
> Cheers,
> ~ol
>
> On 18/06/08 11:04 PM, "Martin O'Neal" <martin.oneal at corsaire.com> wrote:
>
>
>> It's mildly troubling to hear
>> the contrary so forcefully defended.
>
> LOL; all your examples have used a broken SSL implementation to justify
> layering on hashing.
>
> Martin...
>
>
> ----------------------------------------------------------------------
> CONFIDENTIALITY:  This e-mail and any files transmitted with it are
> confidential and intended solely for the use of the recipient(s) only.
> Any review, retransmission, dissemination or other use of, or taking
> any action in reliance upon this information by persons or entities
> other than the intended recipient(s) is prohibited.  If you have
> received this e-mail in error please notify the sender immediately
> and destroy the material whether stored on a computer or otherwise.
> ----------------------------------------------------------------------
> DISCLAIMER:  Any views or opinions presented within this e-mail are
> solely those of the author and do not necessarily represent those
> of Corsaire Limited, unless otherwise specifically stated.
> ----------------------------------------------------------------------
> Corsaire Limited, registered in England No. 3338312. Registered
> office: Portland House, Park Street, Bagshot, Surrey GU19 5PG.
> Telephone: +44 (0)1483-746700
>

----------------------------------------------------------------------------
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