Is it possible to restrict a user to single login instance ?

[Mandar Vaze]

This is related to possible security issue. I've written "privately" to Massimo and Anthony (in another email on this list - they suggested that security issues not be discussed "publicly" on this list)

Lets say UserA logs in successfully from MachineA
now without logging out from MachineA - UserA logs in from MachineB

Is it possible to either :
not allow login from MachineB (show message that "You are currently logged in from MachineA - continue to access the application from MachineA, or logout from MachineA"... or some such message.)
OR
allow login from MachineB - but forcefully log out userA from MachineA (since login from MachineB was later)

Either case - UserA is logged in only once from any machine/browser

I prefer second option - cause the (legitimate) reason why UserA is logging in from MachineB is because s/he doesn't have access to MachineA (at this point)

-Mandar

[Niphlod]

you should track somewhere that userA from machineA is in there and check when userA logs in from machineB.
There's a pretty outstanding issue in your design, though.... how do you recognize machineA from machineB ?

[Anthony]

You could check things like IP address and user agent, but these are imperfect identifiers (generating false positives and false negatives). You should also decide if you really need this level of security, as users may legitimately want to be logged in from multiple places (e.g., from laptop as well as tablet or phone). I'm currently logged into Google Groups from three different devices and would be quite annoyed if I had to keep logging in again when I move between devices.

Anthony

[Mandar Vaze]

I agree that this could be annoying, but the request came from "customer" :) - We are trying to negotiate this down, but in the mean time I would like to be prepared, if this becomes "hard" requirement.
(As I explained - this is also tied to security issue - I'll write to you separately)

Anyway - assuming that I decided to add these checks, where in the "flow" should these checks go ? (and prevent login/invalidate the older session)

-Mandar

On Wednesday, October 15, 2014 1:18:19 AM UTC+5:30, Anthony wrote:

You could check things like IP address and user agent, but these are imperfect identifiers (generating false positives and false negatives). You should also decide if you really need this level of security, as users may legitimately want to be logged in from multiple places (e.g., from laptop as well as tablet or phone). I'm currently logged into Google Groups from three different devices and would be quite annoyed if I had to keep logging in again when I move between devices.

e

[Mandar Vaze]

Thanks for the pointers.
If I decided to add this check - where in the code/flow should this check go ?

-Mandar

[nick name]

On Tuesday, October 14, 2014 9:01:19 PM UTC+3, Mandar Vaze wrote:

Is it possible to either :
not allow login from MachineB (show message that "You are currently logged in from MachineA - continue to access the application from MachineA, or logout from MachineA"... or some such message.)
OR
allow login from MachineB - but forcefully log out userA from MachineA (since login from MachineB was later)

You need to identify machine a or machine b. This is not a trivial problem - IP address may change because of ISP proxies (false positive) and may be unified because of ISP (e.g. two unrelated people using a mobile connection may come out with the same IP address) . The common solution is to look for a unique cookie you set (e.g. My-Computer-Identifier:) and if it doesn't exist, set it to some random uuid you generate.

Then, allow just one such cookie to be acceptable at the same time. If a different cookie arrives, either refuse or require a new login and replace it.

But note that this is also not foolproof - some browser syncing extensions will sync cookies as well.

[Mandar Vaze / मंदार वझे]

All,

Let me clarify a little - since lot of answer seemed to focus on "MachineA Vs MachineB"

What I need is "only one valid session from UserA at given point" - so two sessions - one from Chrome and other from Firefox - both from MachineA - should be disallowed. (Not sure if it makes problem easy or difficult)

Theoretically I am thinking following :

in pre-login (if I can intercept login attempt) - put a code that checks whether user that is trying to login - has already logged in (and not logged out yet) If yes, do not allow the login (or somehow forcely invalidate "other" session - and allow "this" login attempt to go thru)

But I am not sure how this maps to web2py flow/hooks etc.

So pointers w/ specifics above would help.

Thanks,

-Mandar

--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to a topic in the Google Groups "web2py-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/web2py/Z3gjaLzM65E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to web2py+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Anthony]

Let me clarify a little - since lot of answer seemed to focus on "MachineA Vs MachineB"

What I need is "only one valid session from UserA at given point" - so two sessions - one from Chrome and other from Firefox - both from MachineA - should be disallowed. (Not sure if it makes problem easy or difficult)

You still need to be able to distinguish one machine/browser from another in order to know whether a given login request is coming from a different client. The user agent will tell you if a different browser is being used (though it can be spoofed, so this is not a security measure), but that won't help if someone is using the same browser on two different machines (also, what kind of app requires that users should not be able to log in from different browsers on the same machine?). And as already mentioned, there are limitations to using IP address to uniquely identify machines.
 

Theoretically I am thinking following :

in pre-login (if I can intercept login attempt) - put a code that checks whether user that is trying to login - has already logged in (and not logged out yet) If yes, do not allow the login (or somehow forcely invalidate "other" session - and allow "this" login attempt to go thru)

Maybe add a session_id field to db.auth_user, and when a user logs in (a) check that field, and if it has a value, delete the session file associated with the existing ID (if it exists) and (b) store the new session_id. Note, this won't work with cookie based sessions -- in that case, you would instead have to check the session_id value stored in db.auth_user on every request in order to catch and invalidate the session cookie from the older session (this adds a db lookup to every request -- might want to cache these in RAM, though you may need to clean up periodically if there are a large number of users).

Also, note that this doesn't protect against session hijacking. It only protects against multiple simultaneous logins (which would be using different sessions rather than sharing a single hijacked session).

Anthony

[Anthony]

 

Theoretically I am thinking following :

in pre-login (if I can intercept login attempt) - put a code that checks whether user that is trying to login - has already logged in (and not logged out yet) If yes, do not allow the login (or somehow forcely invalidate "other" session - and allow "this" login attempt to go thru)

Maybe add a session_id field to db.auth_user, and when a user logs in (a) check that field, and if it has a value, delete the session file associated with the existing ID (if it exists) and (b) store the new session_id. Note, this won't work with cookie based sessions -- in that case, you would instead have to check the session_id value stored in db.auth_user on every request in order to catch and invalidate the session cookie from the older session (this adds a db lookup to every request -- might want to cache these in RAM, though you may need to clean up periodically if there are a large number of users).

Also, note that this doesn't protect against session hijacking. It only protects against multiple simultaneous logins (which would be using different sessions rather than sharing a single hijacked session).

And keep in mind that this isn't really a security measure -- if an attacker has obtained the login credentials of a user, you are letting the attacker log in. For this to help with security, you would have to warn the original user about a login taking place from a new client.

In any case, I don't think restricting logins is a common security practice. Even banks will let you log in from multiple devices.

Anthony