Deployment practices (Re: Current state of editor's draft / IdentitySignal)

On 2007-08-24 14:00:49 -0400, Mary Ellen Zurko wrote:

> Section 7 could use a comment tracking potential inclusion of 
> http://www.w3.org/2006/WSC/wiki/RobustSharedSecret as well. 

done

http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-trustedpath

> "This specification requires that web pages MUST NOT include
> trust indicating images such as padlocks in the web content."

> This one is still a bit vague. Sites will certainly want to say
> they're trustworthy. And they're want to use images that indicate
> they are. It seems unreasonable to say they can't. What we seem
> to want to be saying is do not use trust indicators that are
> easily confused with security context indicators in deployed web
> user agents. 

Yes.  Anil, mind giving this another stab?

> "Cookies on unsecure connections are vulnerable to interception, and can 
> be used for replay attacks even if they were set by a secure server, "

> I'm on the fence on this whole one.  While that's true of cookies
> themselves, it's not necessarily true of all credentials today,
> or of the future. Is it possible to construct SAML that is not
> vulnerable this way?  I can imagine tying cookie content to IP,
> which would require another level of attack (IP spoofing). 

Well, in the days of lots of wireless networks, IP-level MITM
attacks are actually pretty easily done.

> Is there anything that could be done with IPSec, or are the
> levels all wrong? As a security person I like this
> recommendation, but practical experience shows that it's not
> followed, and I'd very much like us to understand the counter
> arguments. 

One counter argument that I've been given (and find plausible) goes
as follows: A large Web property, let's call it l.com, has lots of
services running under l.com.  They have so many services that they
actually manage them in multiple security tiers, and focus their
resources on securing the services that are security critical.  That
includes:

- Anything that touches real user passwords (or hashes of passwords,
  or anything that one could run a brute-force mechanism against).

- Anything that touches SSL certificates and can therefore more
  plausibly impersonate the rest of the service.

The solution is to have two tiers of authentication: You've got
cookies for the login site (and very regularly are asked your
password there; this information always travels through TLS), and
you've got transient cookies that are bound to individual services
and are used to authorize access these services.  These are often
transmitted through plain HTTP, under the hypothesis that your
account information and credit card is likely more valuable to an
attacker than your compilation of daily news.  These cookies cannot
be used to access the login service, or obtain cookies for yet
another service, and they expire after a while.

In this case, avoiding TLS actually serves to reduce the attack
surface for the really sensitive services, which seems to make a lot
of sense as a deployment practice.

So, no, this isn't easy at all.

> "Web Sites that require their users to be redirected from an
> unsecure web page to a secure web page MUST do it as a single
> step rather than multi-step (redirect to an unsecure page and
> then redirect again to a secure page). "

Actually, we probably need to be clearer in this text -- multi-step
redirects *can* be done in a reasonably secure way, and are
independent from redirects by way of insecure pages.

> Remind me why (I feel like I keep asking for that; see my comment
> about annotations above). 

A redirect through an insecure site would create an attack surface
for a MITM attack that moves you to an attacker-chosen TLS site by
circumventing (not breaking) the TLS protections, and without
interrupting your habituated flow of interaction with the secure
site that you think you're dealing with.  With the current UI (or
even with a better page indicator), that's about as bad as it gets,
even for a paranoid user like myself.

The dual to this is in section 4.5.2, Redirection chains, where we
say a "change of security level" is deemed to occur if sites break
this deployment requirement.

  http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#change-redirects

Incidentally, there is an interesting tension between the cookie
argument above and this particular discussion.

Regards,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Saturday, 25 August 2007 10:40:35 UTC