Assurance

["Joe St Sauver" <>]

Hi,

Steven commented:

#> bearbucks.meteor.com appears to be down, so I can't check directly, but
#> I'm assuming that the Javascript was loaded from the web page, and run
#> in the user's browser, correct?
#
#No.
#
#The javascript runs completely within the server platform. That's 
#something that's new....

If it's server side, it doesn't really matter if it's Javascript or Python
or PHP or C or ... At that point, the key thing is "Can the user trust the 
site to which they're connecting?"

The only clue the user has in this regard typically relates to:

-- the site's domain name (which may not be trustworthy if the site 
   doesn't use DNSSEC to sign its zone, and the user's local recursive 
   resolver doesn't validate those signatures), or something like
   DNSChanger malware is installed on the user's workstation, and/or 

-- the certificate presented by the site.

Since most users can't trust the DNS, it all really devolves to the cert the
site presents.

Unfortunately, we know that users will routinely make poor choices when it
comes to assessing the trustworthiness of certificates they see, trusting
those that they shouldn't, and rejecting at least those that may in fact 
be valid.

EV (so-called "green bar" certs) were meant to help reduce some of that 
risk, but:

-- EV cert uptake/deployment has been limited

-- users appear to not "get" what the green bar implies

#As  you say, *should*. However, if its identical to the application's 
#login page, then the user would have to look at the url bar... does 
#anyone know of anything that could be embedded in the real page, but not 
#duplicated in the fake page ?

If you can create content in a real page, it can normally be duplicated in
a look-alike page, right? The content of the body of a web page is
entirely within the control of the page's author.

#> #Most worrisome, tho, is that we think that if we implemented some forms
#> #of two factor in the authN process of our apps that this proxy could
#> #quickly evolve to handle the extra step.
#>
#> True, for some forms of multifactor, harder for others.
#
#Joe,
#
#could you provide a quick summary of forms which can be abused by this 
#sort of proxy, and which forms might succeed at protecting the application ?

Anything that relies on a user supplying secret information to a potentially
insecure communication channel is at risk from a synchronous attack.

The classic example of a form of two factor that's easily defeated: 

Hardware/software TOTP (RFC6238)/HOTP (RFC4226) tokens. You know, the
user is prompted to enter a string of digits from a hardware token that
they've been issued. That string is only usable once and for a finite 
time, but a malicious application can solicit that string and then,
as it is given to them, it can login in as the user in the background 
in real time (assuming it has also been collected the user's username
and password).

About the only multifactor option that is NOT at risk of being MITM'd 
in a web context would be carefully dployed client certificates (as 
more-or-less required for NIST 800-63 LOA-4). Unfortunately, as we're 
increasingly seeing, a lot of the certificate handling code that's 
actually deployed may have security-exploitable bugs that undercut 
the trustworthiness of those approaches, too.

This includes well publicized things like the Apple Mavericks SSL 
"gotofail" bug ( https://www.imperialviolet.org/2014/02/22/applebug.html ) 
and the recent GNUTLS bug 
( http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0092 ), but 
also the routine issues in OpenSSL as documented at 
http://www.openssl.org/news/vulnerabilities.html (plus at least some of the
bugs at http://rt.openssl.org/NoAuth/Buglist.html (note the 1492 items-not-
filed below the top couple of categories)).

Buggy as the SSL/TLS code quality may be, that code is relatively mainstream
(aka widely deployed and thus relatively widely scrutinized). The PKI/client
cert code is far more obscure/less well tested. An example from just earlier 
this week, on the client cert side of things:
https://www.imperialviolet.org/2014/03/03/triplehandshake.html

As another example, consider the DOD's experience with client certs in the
form of CAC/PIV cards; http://militarycac.com/faqs.htm#TOP_10 is illustrative
of the difficulties that people have had in that space when deploying client
certs on smart cards at scale.

It's a hard problem.

Regards,

Joe