Possible to prohibit Account Sharing ?
2 ビュー (過去 30 日間)
古いコメントを表示
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.
2 件のコメント
Image Analyst
2022 年 7 月 28 日
Do you mean like detect if the IP address of the person logging in is not the same as the original person?
採用された回答
Walter Roberson
2022 年 7 月 31 日
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.)
その他の回答 (2 件)
Walter Roberson
2022 年 7 月 28 日
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.
Image Analyst
2022 年 7 月 28 日
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.
6 件のコメント
Image Analyst
2022 年 7 月 30 日
You could use fingerprint identification or face recognition if it's really important enough to control who uses the program.
参考
カテゴリ
Help Center および File Exchange で Image Processing and Computer Vision についてさらに検索
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!