[Bug 11912] HTML5 provides an opportunity to fix a long-running problem with HTTP Authentication. HTTP Authentication is important, because it is the only way to execute a request with 100% certainty that the user has provided an authentication secret. Furthermore,

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11912

--- Comment #9 from Jeremy <jeremy@blazonco.com> 2011-02-02 18:15:53 UTC ---
(In reply to comment #8)
> 
> > I'll try to stop debating now.
> 
> I actually think we're making progress.

You do?  I'm happy to keep up the debate; I'm just worried about the half-dozen
people who get CC'ed every time we post a reply.


> Then it would help your case a lot if you provided specific examples of
> real-world (*not* hypothetical) applications

You keep saying my examples are hypothetical, and I keep saying they're not.  I
use HTTP authentication right now in several of my applications.  I can't
really show you, because you're not one of my users.  Sorry.  I have worked out
a complicated system of JavaScript to let me use a login form for HTTP auth in
most browsers, and for browsers that don't support that (webkit, Opera) the
users are prompted for their credentials using the UA's native dialog.  Then,
when they want to log out, I need a page explaining to them how to do that and
why they must do it this way.  Fortunately, my users are pretty smart and they
understand; I haven't had any complaints about it.  But not everyone has that
luxury.  And it would be really nice if my users didn't have to deal with that
either.  But they do, because while HTTP authentication is more or less
complete from a *technical standpoint*, it's incomplete from a *user
experience* standpoint.  And that is what we have an opportunity to fix in
HTML5.  Isn't one of the goals of the new standard to improve user experience
for existing technologies?  And to improve security on the web?  Most people
don't use HTTP auth because the user experience is inferior.

And yes, I use the credential forwarding system I spoke of before.  I may not
have quite as many users as Wikipedia, but my database doesn't seem to have a
problem with it (PostgreSQL).  I also don't have *nearly* as much hardware as
Wikipedia has.

> explained a specific real-world attack that could be carried out on those
> applications, and explained how HTTP auth would have prevented that attack.  If
> the application is secret or in-house, you could give a basic rundown of how
> it's set up, as much as is necessary to understand the attack.
> 

So you want a real-world *attack* scenario?  OK.  I happen to have an
installation of MediaWiki on a shared hosting environment.  I'm not going to
publish where it's hosted or what the URL is, because it *is* vulnerable to
attack.

My shared host (a very popular one) has PHP set up with the *default* session
store, which is flat files in /tmp.  This directory is readable to anyone. 
Usually, the flat files themselves are only readable to the user that created
them.  But for the case where someone wants mod_php for their domain instead of
FastCGI, the files must be created as the apache user.  Despite warnings about
the security implications of this, mod_php is a popular choice, because it's
the only simple way to get certain features like full header and environment
information.  And this is not hypothetical; I can easily see that a lot of
people on my shared box are, *in fact and in the real world* using mod_php.

Since I am on that shared server, I can easily execute arbitrary code as the
apache user.  My MediaWiki has an admin account called WikiSysop, and let's say
someone else who has shell access to that box (remember, it's a shared server)
wants to login as WikiSysop and wreak havoc:

[mybox]$ grep WikiSysop /tmp/*
/tmp/sess_4i34n8ih9kr3afticmr4i6kp73:wsUserID|i:1;wsToken|s:32:"177cb3a9c9d0fbbcf624295d59329375";wsUserName|s:9:"WikiSysop";wsLoginToken|N;

Whoops.  Looks like WikiSysop is currently logged in, and I have all the info I
need to steal his session.  I have the session ID (it's part of the filename:
4i34n8ih9kr3afticmr4i6kp73), I have the User ID, and the UserName.  These three
values simply go into some cookies, and in a flash I am logged in as WikiSysop.
 I just tested this attack in the real world.  And it worked.  That's about as
real-world as I can give you, because I'm not going to go ahead and break into
someone else's site.

> 
> With cookies, there's not much need to save passwords.  Lots of sites will let
> you stay logged in for months or forever without having to re-enter your
> password.  But if you use basic HTTP auth, then you either have to re-enter
> your password for every site every time you start the browser, or have it save
> the passwords to disk.  So it will encourage password saving much more
> strongly.
> 

I don't have any statistics on saved passwords.  But lots of people I know,
including myself, use them heavily.  I protect mine with a master password, so
I'm not that worried about it.  I'm not sure if other people do that.  But
anecdotally, whether it's HTTP auth or cookie auth has little bearing on
whether I save the password, even if there is a "keep me logged in for a while"
option.  Eventually I will not be logged in anymore, so I save the password. 
Most people don't even understand the distinction, so it will have even less
bearing for them.

> 
> Yes, but a stolen cookie is much less damaging.  It can have a limited
> lifetime, can be canceled, and doesn't give information about the password
> itself (which is significant when users use the same or similar passwords
> across sites, which most do).  A leaked password is much worse.

I'm not sure I agree with this.  In the attack I executed above, I am now
logged in as WikiSysop without entering his password.  I can do pretty much
anything he can do, short of changing his password (since that requires the old
password - good move).  But by the time that cookie expires or is "canceled"
(not sure how you would figure out that you need to cancel it, "in the real
world"), I can do a lot of damage since I am logged in as what basically
amounts to the root user for that MediaWiki install.

I agree that a leaked password is far more damaging, but to use your own
argument, you haven't provided a "real-world" situation where HTTP auth
invariably leads to a leaked password.  You have just assumed that it's true. 
If you don't want to use SSL on your site, you can use Digest auth instead of
Basic auth.  You lose the credential forwarding ability, but you still remove
the risk of attacks like the one I performed above.  And if you want to talk
real-world, and you want to discount financial or other sites with sensitive
data, then shared hosting is about as real as it gets.  

I know you're going to say that the shared host and the site operator are at
fault for allowing that attack; the shared host should have done more to lock
down those session files, and the site operator shouldn't have chosen mod_php
despite the warnings of the hosting guys, and they shouldn't have been using
flat file sessions in the first place (let alone in /tmp).  But that happens
ALL THE TIME in the real world. A HUGE percentage of shared-host PHP sites are
running with poor security against the other users of that box (and if the
attacker isn't currently one of those other users, he can become one for a low
monthly price!)

If the hosts leave any default settings for PHP or even for the OS in general
(by the way, all the MediaWiki config files are by readable to apache, so I can
also steal other peoples' database credentials, and they can steal mine.  In
the real world.) then they are open for attack.  That could be mitigated by
them fanatically locking down files, forbidding mod_php, using VPS instead of
shared hosting, etc.  But it will be nigh on impossible for them to lock down
every single avenue for people to steal each other's sessions or configs.  If
HTTP authentication were fixed, and if database permissions were proper, there
would *be a way* to prevent session hijacking with 100% certainty (by not using
sessions) and prevent, or at least limit the damage from, database credential
theft.  Currently, most shared hosting customers (probably a large percentage
of your userbase for MediaWiki) simply assume that they're safe, and a lot of
the time they're wrong.  Obviously, they shouldn't assume that -- but they do
in the *real world*.  What if they weren't wrong and they actually *were* safe?
 That seems like a worthwhile goal to me.  Do you agree? 

Somehow, I have a feeling that my descriptions aren't real-world enough; or
that even though I've basically written a dissertation on this by now, you're
going to say I wasn't specific enough about something.  But, as you've probably
figured out already, I love the sound of my own voice and I'm happy to continue
debating the details for as long as you can stand it ;)

Jeremy

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 2 February 2011 18:15:58 UTC