Possible to prohibit Account Sharing ?

Hey,

I am currently in the progress of setting up a Webapp Server to a small user group.

As of now users are required to log in using OIDC over Google Accounts. Is there any way to detect if an user is sharing his Google Account with other Users? Or is there any other provider despite Google where Account sharing would not be possible?

Maybe to clarify it a bit further since it was mentioned in the comments: I would love to check if the same login credentials are logged in twice at the same time at all. And if they are, log out both instances / send a notification.If thats possible by any means it would help out what i am looking for.

If there is any possibility to even combine that with IP Checks, or similar, that would certainly help out but is neither mandatory nor my prefered solution.

Thanks for you replies.

[Image Analyst]

Do you mean like detect if the IP address of the person logging in is not the same as the original person?

[Dominik Pahlke]

Yeah or detect if a user with the same username is logged in twice at the same time. Does not necessarily need to be the IP. I‘d rather just if someone logs in with the same email as someone who is already logged in => force logout both users and send an email to notify the user that his account may have been compromised.

Not quite sure how saving IP addresses for that issue would comply with European data protection laws but pretty sure it would be rather difficult.

Answer 1

[Walter Roberson]

As each person logs in, send them an asymmetric encryption key, and record it against the username.

Exchange packets of data with the user program. At each point, get the current encryption key, and use it to construct a response. Response includes a CRC. Wrap the encrypted response in a second CRC.

If the user program gets a NAK, the packet it last sent was corrupted in transmission, so resend it.

User program checks the CRC of the encrypted response. If it does not check out, the packet was corrupted and NAK it.

If the CRC of the encrypted response checks out, then the user side should use the encryption key to decrypt the packet, and check out the CRC that was decrypted out of the data. If the CRC does not check out, then this session is not longer an authorized session, so quit. If the decrypted CRC checks out, then use the server response.

User program does the same kind of thing, encrypting with the key it was told before.

When the server gets a NAK, resend the previous packet.

When the server gets a packet and the outer CRC does not check out, the packet was corrupt, so NAK it.

When the outer CRC from the user checks out, decrypt the packet according to the current key registered for the user.

If the CRC of the encrypted request checks out, then the user is still authenaticated, so use the data.

If the CRC of the encrypted request fails, then the user logged in again (getting a new encryption key pair), so act appropriately.

Note: this sequence as written permits the user to "abandon" the previous session and log in again (possibly through a different connection), and the new session will not get rejected; everything would be permitted unless there gets to be activity on the previous session as well (in which case bad encryption is detected from the old session, and you know the user is using multiple sessions at the same time.)

[Dominik Pahlke]

Thanks i combined this indea with connection to a SQL Server to store Sessionkeys which does the trick now!

Answer 2

[Walter Roberson]

I'm at home, using my phone to access the site. My local IP address was determined by DHCP on my local 192.168.0.x subnet, and my external IP address is what was assigned by my home ISP.

I leave home and walk to the corner bus-stop. The distance is pretty marginal to continue connecting to my home WiFi, so the home WiFi connection may drop, and I might pick up the open WiFi node run by my ISP, which has a device in the hair dresser on the opposite corner of the street from the bus stop. My IP address becomes whatever was assigned by the ISP WiFi.

The bus arrives, I get on and it starts to drive. I get out of range of the WiFi node run by my ISP, and my phone automatically switches to cell phone data; my IP address becomes an IPv6 address gatewayed by my ISP to IPv4 if needed. Unless, that is, the bus just happens to be one of the ones that has WiFi on it, and I happen to have configured to accept that WiFi.

As the bus happens to have a stop close to a Starbucks, while we are near enough there, my phone detects the WiFi connection from Starbucks and switches to that (instead of using cellular data), and my IP address becomes something else.

Now, I might not have been the only person at home accessing the service, so routinely at home multiple users might be sharing the same external IP address, with distinct local addresses. The ISP open WiFi node has a whole bunch of people sharing the same external IP address. My cellular data service has a whole bunch of people sharing the IPv6 / IPv4 gateway. Starbucks has a number of people sharing the same IP address.

So... you cannot reliably tell different people apart by their IP address, and the same person might very legitimately have a number of different IP addresses.

[Dominik Pahlke]

Yes this is very true, even tho the program i developed would probably not be carried arround as much. The idea is more about detecting the same user being logged in twice.

Answer 3

[Image Analyst]

Maybe you need to use a sophisticated license checking program like Mathworks uses when a bunch of users check out licenses from a pool of available licenses. So they login somehow and if they're already logged in, you can prevent them from logging in again.

[Dominik Pahlke]

Yeah that would certainly be a possibility. Even tho my usergroup is rather small so i'd need to have a cost effective way to include that with matlab WebApp Server. Dou you happen to know if there is any such possibility?

[Image Analyst]

No, sorry. Why do you need to prevent the same user being logged in twice? What happens if they do?

[Dominik Pahlke]

One user could share their account access with another user which would be bad if i want to keep the app on a small user base.

Someone sharing his/her account with someone else so one could get the benefits of the app without having proper access is a huge issue for me.

[Walter Roberson]

Does the webapp have access to permanent storage?

[Image Analyst]

You could use fingerprint identification or face recognition if it's really important enough to control who uses the program.

[Dominik Pahlke]

It runs on a dedicated root server - so yes it should be possible to permanently write data there.