Subject: [saag] Password Discussion

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Jul 2012 21:15:40 +0300

Hi all, 

given the longer discussion related to passwords I thought it makes sense to point you to a document we had written about various problems related to Web security: 
http://tools.ietf.org/html/draft-tschofenig-secure-the-web-03

Ciao
Hannes

PS: I case you want to hear my view on standardizing a new authentication mechanism (whatever it might be) or even an entire authentication framework then I have to say that we have to take the recent developments in the W3C into consideration and the work on the JavaScript CryptoAPI looks very promising to me. With it an identity provider can write their favorite authentication protocol and send it to the browser. No need for standardizing a new authentication protocol anymore nor a framework either. JavaScript is the framework....

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 16 Jul 2012 21:47:33 +0300

Hi Hannes,

I may be missing something big, but I'm puzzled by your postscript below.

First, if you want the actual connection to the server (or to any kind 
of trust anchor, IdP and the like) to be secure, you need the entire 
protocol implementation to be trusted. Untrusted JavaScript on top of a 
trusted crypto layer won't cut it.

As a result, I see very little value in a standard crypto API for 
JavaScript, compared to "industry-standard" libraries like JQuery. A 
standard crypto API certainly won't hurt, but I'd be surprised if it has 
a significant effect on Web security as a whole.

On the other hand a widely deployed HTTP authentication mechanism, if 
it's good enough (for whatever value of "good enough") could make a real 
difference.

Thanks,
	Yaron

On 07/16/2012 09:15 PM, Hannes Tschofenig wrote:
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Jul 2012 12:08:26 -0700

In addition, an authentication "framework" that relies on Javascript kinda bolloxes all proxies, yes? That seems like an architectural change that might not be considered completely positive, to say the least.

--Paul Hoffman

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Jul 2012 22:07:31 +0300

Hi Yaron, 

On Jul 16, 2012, at 9:47 PM, Yaron Sheffer wrote:

> First, if you want the actual connection to the server (or to any kind of trust anchor, IdP and the like) to be secure, you need the entire protocol implementation to be trusted. Untrusted JavaScript on top of a trusted crypto layer won't cut it.

You do what everyone does: you use TLS with server-side authentication (assuming you have solved the PKI issues)
The CryptoAPI addresses the client-side authentication. 

> 
> As a result, I see very little value in a standard crypto API for JavaScript, compared to "industry-standard" libraries like JQuery. A standard crypto API certainly won't hurt, but I'd be surprised if it has a significant effect on Web security as a whole.

Could you expand on your concern regarding JavaScript (given that we seem to be doing everything else in JavaScript as well these days, including our favorite protocols)? 

> 
> On the other hand a widely deployed HTTP authentication mechanism, if it's good enough (for whatever value of "good enough") could make a real difference.

*widely deployed* is exactly the problem. 

Why would someone widely deploy something now when there are better ways waiting just around the corner. 

Ciao
Hannes

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Jul 2012 12:13:31 -0700

> Why would someone widely deploy something now when there are better ways waiting just around the corner. 

Security? Interoperability? Scalability? Just a few thoughts.

--Paul Hoffman

---

From: Mouse <[email-masked]>
Date: Mon, 16 Jul 2012 15:24:34 -0400 (EDT)

> PS: I case you want to hear my view on standardizing a new authentication me$

What about people who care enough about security to be unwilling to run
code presented by other machines (like JavaScript)?  I know *I*
certainly am not going to be participating in anything that requires me
to run JavaScript code - or code in pretty much any other language -
offered to me by arbitrary sites.  Are such users simply outside the
target you're designing for, or is this a way to "persuade" them to
shut up and drink the nice koolaid, or what?  I doubt I'm alone in
finding suspicion that it's the latter is one of my first reactions,
however unjustified.  Even if that's not what _you_ mean by it, I
suspect it's something it will rapidly get abused for.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 16 Jul 2012 22:30:29 +0300

Hi Hannes,

> The CryptoAPI addresses the client-side authentication.

Well, I'm not assuming we have solved the PKI issues. In fact I'm not 
sure we can ever solve them.

> Could you expand on your concern regarding JavaScript (given that we seem to be doing everything else in JavaScript as well these days, including our favorite protocols)?

That ties into the previous paragraph, i.e. you cannot trust the 
downloaded code because you cannot trust the server-side authentication.

In addition, the JavaScript sandbox model has had its problems. The 
latest incident is Microsoft's recommendation to avoid using their 
Gadget architecture.

> Why would someone widely deploy something now when there are better ways waiting just around the corner.

Actually, if we put the security concerns aside, and just look at market 
deployment, JQuery has been a major success because it can be downloaded 
with the application, and the application does not need to rely on 
browser features to use it. The W3C effort is taking the opposite 
approach, and so it will likely be a long time before it is adopted.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Jul 2012 22:31:17 +0300

Hi Paul, 

who says that the JavaScript CryptoAPI isn't secure? Why are building the rest of the Web and smart phone applications on JavaScript then why not also the security stuff. 

Interoperability: the interoperability comes through the JavaScript API but you don't have to standardize all the different authentication protocols. Just a different form of interoperability. 

I wonder what scalability you are concerned with?

Ciao
Hannes

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Jul 2012 12:49:24 -0700

On Mon, Jul 16, 2012 at 12:24 PM, Mouse <[email-masked]> wrote:
> offered to me by arbitrary sites.

So you basically don't use the Web or view PDF files?

-Ekr

---

From: Mouse <[email-masked]>
Date: Mon, 16 Jul 2012 15:51:45 -0400 (EDT)

> downloaded code because you cannot trust the server-side

Well, but you also cannot trust the downloaded code even if you _do_
trust the server-side authentication, in many cases.  Even the best of
organizations get cracked eventually, and, even if they haven't been
cracked, their priorities generally do not match well with mine, so the
tradeoffs that it is in their interest for me to make are usually not
the ones it is in my interest to make.  And then there are inside
threats and various other, more arcane, threats.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Mouse <[email-masked]>
Date: Mon, 16 Jul 2012 15:54:59 -0400 (EDT)

> who says that the JavaScript CryptoAPI isn't secure?

Umm...anyone who's looked at the security history of JavaScript, or for
that matter of most other attempts to build client-side sandboxes?

Also, "secure against what?".  It may well be - I'd even go so far as
to say "probably is" - secure against some relevant threats but not
others.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Jul 2012 21:17:39 +0100

So I don't think we need go debate all the detail of the
security level of JS to be honest. (I'm not trying to
stop you, but maybe change the subject line.)

>From my p-o-v, JS developers exist and will do stuff.
If left alone that'd probably be the usual md5("password"),
and they'd call that a signature and think they're done.

I reckon we ought standardise a working & usable non-password
based scheme (if we can) and then people can use that in
whatever programming environment they want, with whatever
security properties they get. Right now, there's a chance to
get that done and adopted in httpbis, which could (all going
well) result in enough deployment so the JS guys would copy
that. I think that's a good enough win in IETF terms to be
worth it.

Natural selection can take care of the rest.

S.

---

From: Marsh Ray <[email-masked]>
Date: Mon, 16 Jul 2012 15:19:53 -0500

> So you basically don't use the Web or view PDF files?

I browse the web with the Firefox NoScript plugin. From within a virtual 
machine.

For critical things that require web, like online banking, I do them 
from a dedicated system that's not used for anything else.

For systems that need to be maximally-secure (for me personally, that's 
mostly stuff like the family fileserver at home that I don't want to 
spend a whole Saturday rebuilding) I avoid using web-based systems for 
them whenever possible.

I have not run Adobe's PDF reader for many years. When I did, I would 
always turn off the Javascript functionality. These days I use a VM to 
run one of the 3rd party PDF viewers which does not support Javascript.

In my view, this intentional blurring of the distinction between 
documents and applications, i.e., "executable content", is possibly the 
biggest single mistake ever made in the field of data security. At the 
time, vendors rationalized it by claiming it was useful, sandboxed, and 
users couldn't remember the 10 different extensions that Windows treats 
as executable anyway.

History has shown that justification to be wrong, but for even worse 
reasons. Secure application development is so much harder than anyone 
expected and coding practices were so haphazard that even malicious 
document data typically ends up gaining arbitrary code execution 
capabilities.

So, in summary, I don't like Javascript because I believe excessive 
Turing-completeness will attract the wrath of the Gods. Admittedly 
that's not a very well-defined argument, but it tends to be right some 
of the time. Perhaps a better argument is that it has simply proven to 
be an indefensibly large attack surface in practice.

- Marsh

---

From: Mouse <[email-masked]>
Date: Mon, 16 Jul 2012 16:55:14 -0400 (EDT)

>>> I know *I* certainly am not going to be participating in anything
>>> that requires me to run JavaScript code - or code in pretty much
>>> any other language - offered to me by arbitrary sites.

Huh?  Neither of those requires running JS.  Some parts of the Web do;
I simply don't use those parts.  PDF files, as far as I can tell, do
not; certainly most of the PDF files I've run into work fine in
GhostScript (which does not have a JS engine in it as far as I've been
able to tell, at least not in the version I run) or xpdf's pdftotext
(which also doesn't have a JS engine as far as I can tell).

> For critical things that require web, like online banking,

Well, there you are.  I don't consider online banking critical.  In
fact, I won't go near it.  The prices are far too high for me, both the
"must pay" prices and the "chance of paying" expected (in the
statistical sense) prices.

> I have not run Adobe's PDF reader for many years.

I've never run it, at least not on my own machines.  I don't run
software I didn't build from source myself.

> documents and applications, i.e., "executable content", is possibly
> the biggest single mistake ever made in the field of data security.

Quite possibly.  I'm not sure I agree, but I definitely don't disagree.

> Perhaps a better argument is that it has simply proven to be an
> indefensibly large attack surface in practice.

Yeah.  Like various other things in various fields, in theory it might
be fine, but practice has shown it to be a problem.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Jul 2012 13:58:39 -0700

> who says that the JavaScript CryptoAPI isn't secure?

Many people. It depends on your definition of "secure", of course.

> Why are building the rest of the Web and smart phone applications on JavaScript then why not also the security stuff. 

Because they have different properties?

> Interoperability: the interoperability comes through the JavaScript API but you don't have to standardize all the different authentication protocols. Just a different form of interoperability. 

By "different form", you mean "less", yes? That's fine, but it has not worked out so well in the past.

> I wonder what scalability you are concerned with?

Killing off authenticating HTTP proxies reduces scalability. Forcing all browsers to use a specific, current pile of JavaScript before a user can authenticate reduces scalability.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Jul 2012 14:04:03 -0700

> Many people. It depends on your definition of "secure", of course.

Could you explain who those many people are,
what definition of security they are using, and what not secure means?

> Because they have different properties?

Really?

> Killing off authenticating HTTP proxies reduces scalability. Forcing all browsers to use a specific, current pile of JavaScript before a user can authenticate reduces scalability.

As the Web moves more and more towards HTTPS, authenticating proxies
are going to go away naturally.

As for a specific, current pile of JS, you should take a look at how
many pages already require specific
JS in the form of Google Analytics, JQuery, etc.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Jul 2012 14:25:31 -0700

> what definition of security they are using, and what not secure means?

There have already been responders on this list. My definition for security for client authentication means that the server has high assurance that the system they are using to authenticate the client is reliable; we have seen that different versions of JavaScript, and different versions of JavaScript API modules, have different levels of reliability.

>> Because they have different properties?

Yes. For example, the properties needed for "I will give you access to these records based on your identity for these records" are different than "I will let you do this audio interaction with this other person". We would all love the properties to all be based on the highest standards of reliability for JavaScript implementations and API implementations; history has proven otherwise. This isn't to say that JavaScript sucks for everything, or even for some uses in client authentication, just that Hannes' argument that we don't need to develop new HTTP client auth mechanisms because they can be done in JavaScript APIs in the future assumes a set of properties that not everyone agrees with.

> are going to go away naturally.

Fully agree. But as the deployed Web goes away from HTTPS due to questionable firewall policies (including proxy-in-the-middle attacks), those proxies will remain with us.

More important, as the Web goes more toward HTTPS, we might be able to greatly reduce the need for HTTP authentication. But that's not what Hannes is arguing for.

> JS in the form of Google Analytics, JQuery, etc.

I have done so. That pile is impressive. Adding to that pile does not necessarily give the security properties that people want for authenticating HTTP clients.

--Paul Hoffman

---

From: Marsh Ray <[email-masked]>
Date: Mon, 16 Jul 2012 16:28:39 -0500

On 07/16/2012 03:58 PM, Paul Hoffman wrote:
>> Interoperability: the interoperability comes through the JavaScript
>> API but you don't have to standardize all the different
>> authentication protocols. Just a different form of
>> interoperability.
>

With the entry of Google and Apple into the browser game, the security 
of browser implementation code has gotten much much better. So let's 
just grant for the sake of discussion that the mainstream browsers 
provide perfectly secure Javascript implementations on which to build 
new authentication and encryption mechanisms.

But what does it take to get there? All the current Javascript 
implementations took years and years of bug-after-security-bug slogging 
by huge engineering teams to get to the point where they are now.

Right now there are many open source Javascript implementations that 
could be used as a starting point for someone wishing to implement a 
protocol endpoint. Wikipedia lists over a dozen. But probably only two 
or three are battle-hardened to the point that we should consider using 
them for building systems with real security requirements, and these are 
the same ones that are in the browsers!

So, yes, ECMAScript is an open international standard and open source 
implementations are available. But when the security requirements are 
real, it is impractical for any but the very largest organizations to 
develop a new implementation. In practice it appears that the 
specification is co-defined along with the implementations.

It seems to me very un-IETF-like to define a protocol with such onerous 
dependencies that a clean, secure reimplementation from spec is all but 
impossible.

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Mon, 16 Jul 2012 16:38:58 -0500

> what definition of security they are using, and what not secure means?

I agree that "not secure" isn't exactly a scientific claim without all 
the critical context being well defined. However, in crypto, the burden 
of proof is on the person claiming the system *is* secure. So when 
critics say something is "not secure" it should at least perk our ears 
up and listen to what they have to say.

But complexity breeds security bugs. So even beyond that, any 
significant new complexity needs to have a really good justification for 
existing. As-good is not enough, new complexity needs to be provably 
*more* secure than the status quo in order to be worth considering.

Two of my favorite discussions about Javascript crypto:

Thomas Ptacek, Matasano Security
http://www.matasano.com/articles/javascript-cryptography/

Nate Lawson, Root Labs
http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Jul 2012 14:59:49 -0700

On Mon, Jul 16, 2012 at 2:38 PM, Marsh Ray <[email-masked]> wrote:
> I agree that "not secure" isn't exactly a scientific claim without all the
> critical context being well defined. However, in crypto, the burden of proof
> is on the person claiming the system *is* secure. So when critics say
> something is "not secure" it should at least perk our ears up and listen to
> what they have to say.
>
> But complexity breeds security bugs. So even beyond that, any significant
> new complexity needs to have a really good justification for existing.
> As-good is not enough, new complexity needs to be provably *more* secure
> than the status quo in order to be worth considering.
>

Both of these seem to be about cryptography that is implemented *in*
JS. But the Webcrypto API is about cryptography implemented in
the browser and exposed to JS.

This isn't to say that the webcrypto API is or isn't secure (or will or
won't be when it's done), but it's not clear to me that these
particular arguments apply to a number of the relevant use
cases.

-Ekr

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Jul 2012 12:57:07 +0300

The question of trust in downloadable code is orthogonal to the JavaScript topic since we always use downloadable code even with native applications. 

In fact, not downloading the latest code (automatically) increases your vulnerability to attacks.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Jul 2012 13:03:09 +0300

Hi Yaron, 

On Jul 16, 2012, at 10:30 PM, Yaron Sheffer wrote:

> Well, I'm not assuming we have solved the PKI issues. In fact I'm not sure we can ever solve them.

I am assuming that the Web PKI issues will get addressed and I am proposing to hold an IAB workshop on that topic.  

> That ties into the previous paragraph, i.e. you cannot trust the downloaded code because you cannot trust the server-side authentication.

The application community has bought into the concept of JavaScript and as I explain in my other mail even native code is downloaded. 

So, the question is not really whether you like that concept or not. Take it as a fact that this is what the application community is doing and therefore we have to figure out how to tackle some of the security aspects. 
As this is explained in the draft I distributed. 

> 
> In addition, the JavaScript sandbox model has had its problems. The latest incident is Microsoft's recommendation to avoid using their Gadget architecture.

To my knowledge there is no relationship to JavaScript as such. 

> Actually, if we put the security concerns aside, and just look at market deployment, JQuery has been a major success because it can be downloaded with the application, and the application does not need to rely on browser features to use it. The W3C effort is taking the opposite approach, and so it will likely be a long time before it is adopted.

I am not sure I am following your line of argument here. 

JQuery is a JavaScript library. It is used by Web and smart phone developers (as JQuery Mobile) to change the UI in a dynamic fashion. JQuery is just a compilation of useful functions and no new API was developed (like it was true with the HTML5 bundle that added all sorts of new APIs). 

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Jul 2012 13:06:23 +0300

JavaScript has lead to an architectural change but that happened a while ago. 

We (some folks in the IAB) had tried to raise this issue in http://tools.ietf.org/html/draft-tschofenig-post-standardization-02 and with the Prague IETF plenary. The upcoming plenary will touch on the topic of mobile code distribution again by looking at other ongoing developments (outside the Web space). 

The application community decided to use it and here we are. 

The JavaScript CryptoAPI does not cause more or less problems for proxies than regular JavaScript code does. So, I don't see the issue.

---

From: Mouse <[email-masked]>
Date: Tue, 17 Jul 2012 11:23:53 -0400 (EDT)

[top-posting and no-trimming damage repaired manually]

> The question of trust in downloadable code is orthogonal to the JavaScript t$

"We" do?  "Always"?  _I_ certainly don't.  If _you_ want to turn over
control of your machine to anyone whose website you visit, or anyone
who happens to have cracked the hosting for website you visit, that's
_your_ neck.

> In fact, not downloading the latest code (automatically) increases your vuln$

While downloading it increases your vulnerability to (other) attacks.
(Well, downloading it and running it, but that's true of both.)

There's also a huge difference between installing an update to an
application from its provider (which is what I assume you're talking
about here) and running more or less arbitrary code offered up by a
webpage you have no relationship to beyond looking at.

For my purposes, I do applicatino-level updates relatively rarely and
always with human intelligence inserted between "download" and "run".

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Jul 2012 11:37:17 +0300

Hi

> who happens to have cracked the hosting for website you visit, that's

To quote Ekr from http://tools.ietf.org/html/draft-ietf-rtcweb-security-03: 

"
      Users can safely visit arbitrary web sites and execute scripts
      provided by those sites.
"

That's the threat model for the browser environment. 

That's very different to the threat model for downloading native code. 

> always with human intelligence inserted between "download" and "run".

I would love to cite some papers now that confirm that not downloading patches automatically leads to increased vulnerabilities.
I have to search for them. 

Ciao
Hannes

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Jul 2012 06:03:14 -0700

> That's very different to the threat model for downloading native code.

In fairness, I think that Mouse is arguing that browsers don't deliver  on
that guarantee...

-Ekr

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Jul 2012 16:53:13 +0300

> In fairness, I think that Mouse is arguing that browsers don't deliver  on

That's OK. 

I do not have an overview of what caused security vulnerabilities in browsers the last few years. 
I am not sure it is fine to put all browser related aspects in one bucket, particularly if I think about Flash, and Java vulnerabilities in comparison to what is happening around JavaScript.

---

From: Chris Palmer <[email-masked]>
Date: Thu, 19 Jul 2012 10:58:40 -0700

> I have to search for them.

http://www.techzoom.net/publications/silent-updates/

Although Eric is right that we don't always deliver on the guarantee,
the only way we can even begin to is in the latest stable version. :)

---

From: Chris Palmer <[email-masked]>
Date: Thu, 19 Jul 2012 11:06:17 -0700

> I do not have an overview of what caused security vulnerabilities in browsers the last few years.

Here are two examples:

http://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1.html

http://blog.chromium.org/2012/06/tale-of-two-pwnies-part-2.html

We consider the sophistication and difficulty of these exploits to be
a good sign.

---

From: Mouse <[email-masked]>
Date: Mon, 23 Jul 2012 12:21:24 -0400 (EDT)

> That's very different to the threat model for downloading native

It is.

I fear it also is living in a fantasy land.  It's easy to achieve by
weakening the language used by the scripts in question, but there is a
constant tension between script authors, who want a powerful language,
and security, which wants a weak language.  So far, security has been
the loser in that fight, and, as long as it continues to be, I don't
expect the above ideal to become reality.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 30 Jul 2012 13:10:26 -0700

Just to round out this thread, a literary contribution from McSweeney's Internet Tendency.
<http://www.mcsweeneys.net/articles/your-password-must-contain-the-following>

YOUR PASSWORD MUST CONTAIN THE FOLLOWING.

BY ERIC K. AULD

- - - -
1. A capital letter.

2. A number.

3. One of the following symbols: !@#$%^*()<>?∑©ϠДϪЩўӹԊ฿⌂↨&.

4. Your favorite color.

5. Your favorite brand of gin.

6. The exact date/time of your first blood clot.

7. Three distinctly different recipes for lemon basil chicken.

8. A 2000-word essay on your opinion of Pluto’s non-planetary status.

9. That joke—you know, the one with the guy in the raincoat.

10. An mp3 of you humming Wagner’s Ride of the Valkyries in the shower.

11. Your perfect Sunday.

12. A Petrarchan sonnet on the loss of your virginity.

13. One of your kidneys.

14. Your favorite polygon (and why).

15. Your best Stephen Wright impression.

16. An anecdote of that time you asked Julie Hanson out and forgot your own name. You got drunk on Smirnoff and almost fell out the window, then we carried you into the elevator and left you there, and you woke up and your sideburns were gone. You remember that? Man, those were the days.

17. The original battle plans for the invasion of Normandy.

18. Your favorite Brady Bunch child.

19. A modern-day American-English translation of the Epic of Gilgamesh.

20. A lowercase letter.