Re: stopping concurrent logins
Todd White [EMAIL PROTECTED] writes: i'm sure this is not a novel need, but i have failed to find or come up with just yet any (non-cookie) solution yet. i'm trying dearly to avoid cookies, but if that's the best or only way to do this, feel free to speak up. i'd love to hear from someone who has already tackled the problem of stopping concurrent web logins to a protected web space. realizing that ultimately people can share their username/password to a for-fee protected web site, we would at *least* like to avoid the possibility that two people could both be logged in at the same time from two different computers. the use of IP address doesn't seem adequate since many users come through a router/proxy running NAT. Hmm, as people are logged in, there must be some kind of session. So the only thing you need is to make sure that there can be at most one session for given user id - in fact, to invalidate any 'older' session(s) while logging in in the 'new' one. -- ( Marcin Kasperski | In any large change, 1/3 will think it is great, 1/3 ) ( http://www.mk.w.pl | will think it is stupid, and 1/3 will wait (Reed) ) () ( Porady dla programisty Oracle: http://www.mk.w.pl/porady/porady_oracle )
stopping concurrent logins
i'm sure this is not a novel need, but i have failed to find or come up with just yet any (non-cookie) solution yet. i'm trying dearly to avoid cookies, but if that's the best or only way to do this, feel free to speak up. i'd love to hear from someone who has already tackled the problem of stopping concurrent web logins to a protected web space. realizing that ultimately people can share their username/password to a for-fee protected web site, we would at *least* like to avoid the possibility that two people could both be logged in at the same time from two different computers. the use of IP address doesn't seem adequate since many users come through a router/proxy running NAT. any pointers?
Re: stopping concurrent logins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 03 April 2003 20:33, Perrin Harkins wrote: Of course you could also just totally prevent people from logging in again if there is already an active session for that user, but that will cause problems because your sessions will not get invalidated if a user shuts down his browser or crashes his machine. We did just this on our secure server. My boss was worried our customers might share their login accounts (for which they had to pay), so we set up the login authentication so, that only one session could be logged in at any given time. The sessions timed out in a couple of hours, so losing the cookie would not cause permanent loss of access. We later added a button to log out other sessions, if correct user name and password was given for an already open account. After which the user had to login again. The user authentication information was stored into a cookie. The cookie was stored also on the server. Each time the user accessed the secure server, his cookie was verified against the one stored on the server (plus, of course, verifying that the cookie was valid and authorised to access whatever resource he was trying to access). If the cookie matched the one stored on the server, access was granted. If, however, the cookie did not match, the server immediately expired the user cookie and presented a login screen. If he was able to log in, the button to log out the other session would appear, but no cookie was sent to the user, meaning he would need to provide the authentication credentials again. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+jdRrWD8Ca88cV68RAh0CAKCJDGoh0hf864clmwzamz4gChmhsQCfZua1 fLXzhdGbdgzN5zd11LtSHeQ= =2/M8 -END PGP SIGNATURE-
Re: stopping concurrent logins
On Fri, Apr 04, 2003 at 03:34:25PM +0200, Frank Maas wrote: You can set a session (see Apache::Session and related modules) that can use the uri as session-container as well (eg http://www.example.com/9o79876a98d7fa98d7/path/to/doc). The session part (9o79876a98d7fa98d7) can be stored in a database. Success. Technically, that doesn't solve the problem either. Since the session information is in the URL, there is nothing to stop the user from IM that URL to their friend, who then has total access, without a cookie, just by using the current users session. I must not fully understand the taboo against using cookies. It's rare that an online application, e-commerce related or otherwise, works without cookies. If you're doing anything more than browsing static data, you'll quickly become fustrated at the lack of support for non-cookie-enabled browers. Anytime web based authentication is used, people are going to need cookies. Maintaining state and security within a stateless medium is almost impossible without cookies, in my experience. I've heard of, but never seen, authentication using java or flash that maintains a persistent connection in the background using sockets to the web server. This basically registers the user's IP address with the system, and all users with that IP are considered authenticated. I'm sure more complicated solutions exist. Sorry I don't have a solution to your problem. But perhaps the problem is the requirement to not use cookies... :) Good luck, Rob --Frank -- Robert Landrum Systems Programmer
RE: stopping concurrent logins
On Fri, Apr 04, 2003 at 03:34:25PM +0200, Frank Maas wrote: You can set a session (see Apache::Session and related modules) that can use the uri as session-container as well (eg http://www.example.com/9o79876a98d7fa98d7/path/to/doc). The session part (9o79876a98d7fa98d7) can be stored in a database. Success. Technically, that doesn't solve the problem either. Since the session information is in the URL, there is nothing to stop the user from IM that URL to their friend, who then has total access, without a cookie, just by using the current users session. I must not fully understand the taboo against using cookies. It's rare that an online application, e-commerce related or otherwise, works without cookies. If you're doing anything more than browsing static data, you'll quickly become fustrated at the lack of support for non-cookie-enabled browers. On the latter I totally agree. To avoid the session snatching you describe, you can store IP addresses on your site in the database. You won't solve proxyserver-problems with this though. So what about the following approach: * a user logs on and you issue a session, as part of the uri * when the user requests another page, you fetch the session from the uri, check it against your database and (let's assume it's correct) you allow access but while issueing a new session If this works (and as some people consequently add 'untested') then session snatching becomes a hell of a job. If one user logs in, and the other copies the session and retrieves a page, the session changes, so the first user has to copy the new session again. Sounds promising But to return to my first phrase: with cookies it's much more simple. --Frank PS: What I never got though... how 'bout stealing cookies from someones system?
Re: stopping concurrent logins
On Fri, Apr 04, 2003 at 10:13:59PM +0200, Frank Maas wrote: On the latter I totally agree. To avoid the session snatching you describe, you can store IP addresses on your site in the database. You won't solve proxyserver-problems with this though. So what about the following approach: * a user logs on and you issue a session, as part of the uri * when the user requests another page, you fetch the session from the uri, check it against your database and (let's assume it's correct) you allow access but while issueing a new session Interesting idea. I assume that you're keeping the session key/ID in the URL, right? Does it break if someone hits back (and goes to a page that's full of URLs with on old session ID in them) and then clicks on one of them? -Andy
RE: stopping concurrent logins
On Fri, Apr 04, 2003 at 10:13:59PM +0200, Frank Maas wrote: On the latter I totally agree. To avoid the session snatching you describe, you can store IP addresses on your site in the database. You won't solve proxyserver-problems with this though. So what about the following approach: * a user logs on and you issue a session, as part of the uri * when the user requests another page, you fetch the session from the uri, check it against your database and (let's assume it's correct) you allow access but while issueing a new session Interesting idea. I assume that you're keeping the session key/ID in the URL, right? Does it break if someone hits back (and goes to a page that's full of URLs with on old session ID in them) and then clicks on one of them? Yep. I think that the back-button is out of the question in such a solution. Of course one could think of yet another scheme that makes it possible to use the back-button. But a more simple solution is to create a back-link on the page. --Frank
RE: stopping concurrent logins
Robert, When I was designing the security for a perl/cgi system I spent a lot of time on the cookie issue. I don't have any problem myself with servers putting cookies on my machine. The subject happened to come up with one of the guys that works on the LAN at a customer of ours. He is violently against cookies. He is a technical person and works on computers but has this extreme aversion to people tracking what he is doing. I think it's more of a baseless fear of the unknown myself. Anyway, upon further investigation into this, some of the docs I read indicated cookies aren't all that reliable and will get lost if there are too many of them or the data gets too large. Apparently, the spec allows the browser to toss the data if it wants. So, I ended up using hidden variables. It is a bit of a chore, but I have never encountered an objection from a user or a session getting dropped because the data got lost. It certainly avoids the potential controversy that may come up over cookies. Chuck -Original Message- From: Robert Landrum [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 11:53 AM To: [EMAIL PROTECTED] Subject: Re: stopping concurrent logins On Fri, Apr 04, 2003 at 03:34:25PM +0200, Frank Maas wrote: You can set a session (see Apache::Session and related modules) that can use the uri as session-container as well (eg http://www.example.com/9o79876a98d7fa98d7/path/to/doc). The session part (9o79876a98d7fa98d7) can be stored in a database. Success. Technically, that doesn't solve the problem either. Since the session information is in the URL, there is nothing to stop the user from IM that URL to their friend, who then has total access, without a cookie, just by using the current users session. I must not fully understand the taboo against using cookies. It's rare that an online application, e-commerce related or otherwise, works without cookies. If you're doing anything more than browsing static data, you'll quickly become fustrated at the lack of support for non-cookie-enabled browers. Anytime web based authentication is used, people are going to need cookies. Maintaining state and security within a stateless medium is almost impossible without cookies, in my experience. I've heard of, but never seen, authentication using java or flash that maintains a persistent connection in the background using sockets to the web server. This basically registers the user's IP address with the system, and all users with that IP are considered authenticated. I'm sure more complicated solutions exist. Sorry I don't have a solution to your problem. But perhaps the problem is the requirement to not use cookies... :) Good luck, Rob --Frank -- Robert Landrum Systems Programmer
