views:

507

answers:

7

This is something of a rant, as well as a question.

There are some sites, like Facebook, where you would only want to be logged into one account at a time.

But everything from blogging sites to email always force you to logout before you can login to another account.

And I understand the security implications, and how it would make cookie-based sessions a little more complex, but why don't we see more of this?

Why would multiple users from a single client at once be a bad idea?

+7  A: 

I think this is something that should be imnplemented by browsers by allowing multiple sessions, each using their own cookie/authentication/etc.

That would probably be the best solution, as it would seem to work for all sites, and require no updating for them, and, although I don't know much about it, it doesn't seem it would be terribly difficult to implement either.

recursive
And you can have this today - fire up IE, Firefox, Opera, and Chrome; voilà - you can have 4 concurrent sessions. Wait a minute while I fill out my patent application...
Michael Burr
A: 

Cookie state is anchored to the host header...

Use a different hostname or use its IP address directly to connect to the site. Depending on the site you may be able to setup a bunch of local host aliases to the site allowing you to be logged on more than once as each alias would have its own cookie state.

If the site redirects to itself to force a specific host header the aliasing won't work and you'll need to use multiple browsers.

Einstein
+2  A: 

The simple problem is most sessions are implemented via cookies, and there's pretty much no way to do it without cookies.

And the way cookies work, is they're bound to the domain/path, and all cookies tied to that domain are sent.

So if you permit logging in twice via 2 different cookies, the problem would be every successive page would send BOTH cookies, and the server seeing both has no idea which "user" you are acting as.

The only way around this is passing a "thread" identity around all links, ( that is, rewriting every site link on the fly to foo.bar?thread=2 or thread=1 to indicate which session to use for things ), and that is a complete nightmare, not to mention security implications.

The only real way to do it is via browser-sand boxing, the user tells the browser that a given tab and all offshoots use one cookie set, and the other tab and all offshoots use another.

In essence, its not a problem that can be solved by websites in a practical manner.

There's practically no good way to store this information without delegating the controls to how it works to browsers to implement, and for users to manually indicate when they want to fork into a new session.

Single Browser Solutions that should work today:

  • CookieSwap 0.5.1 Appears to permit "state toggles" of various cookie sets, It doesn't do whats needed to be able to just browse them magically, but its a partial solution. I can't test it myself because it hasn't been ported to FF3.1 yet.
Kent Fredric
+1  A: 

One implication of multiple logins is how to manage privileges. Say I have two accounts, one has a privilege to delete user accounts and my other account lacks this privilege.

If I can be logged into both of my accounts simultaneously, which takes precedence, do I have the union of privileges from both accounts, or only the intersection of privileges held by both accounts?

If I have the union of privileges, would I have the ability to combine privileges from these multiple accounts in ways that give me too much power? What does this imply for Sarbanes-Oxley compliance?

An equivalent issue is seen in SQL, with respect to "roles" which are groups of privileges. In standard SQL, a given account is permitted to adopt multiple roles, but only one at a time. This prevents you from exercising too much privilege.

Bill Karwin
+3  A: 

"Why would multiple users from a single client at once be a bad idea?"

It is not a bad idea at all, but the use of HTTP forces us down this route.

Most client/server protocols are stateful - the client need authenticate only once during handshaking and then the session is represented by the socket connection. If you lose the connection, you lose the session and have to re authenticate. It is then trivial to write applications that allow multiple sessions (as the same or different users) in the one process.

HTTP is stateless. The client needs to re-authenticate in some manner with every single request. Authentication information is usually stored in cookies so that the user does not have to be involved once the initial authentication has been done. Cookies, however, are global - not just global with in the process, but generally across instances/invocations of the application. Hence, you are stuck with a single session.

You would have thought that web-app designers would have looked at this massive limitation as a sign that HTTP just isn't the right protocol for client/server application development.

Daniel Paull
A: 

Since you first wrote the question, IE 8 has been officially released and it has a built-in feature that does what you want. From the "File" menu, click on "New Session." This will open a new window that will not share session cookies with the original window, allowing you to be logged into the same site under different logins simultaneously.

http://blogs.msdn.com/ie/archive/2009/05/06/session-cookies-sessionstorage-and-ie8.aspx

David Kolar
A: 

You can do multiple sessions in Firefox by creating new profiles - run: firefox.exe -P which is where you can set up multiple profiles that will have different cookies - you can run multiple sessions of firefox at the same time by using firefox.exe -P "profileName" -no-remote . the no remote will only allow 1 window per session but will also allow multiple sessions at the same time.

Dave