Allow authcookie to be used from a different IP address + extra features
Fusl
First of all, authcookie's should not be bound to a single IPv4/IPv6 address as this would cause several issues with the VRChat client when the IP address changes. Users are still able to join instances through the friends list due to the Photon servers not verifying the authcookie but stuff like the friends list doesn't refresh and shows old information until the client is restarted, at which point a re-login is required since that authcookie seems to be the only thing that VRChat stores across restarts, which also causes users to pick less secure passwords (because who wants to type in a 20 character password with special characters every time they need to restart their game due to this limitation?).
I do understand that implementing this would cause a security risk to be added to the entire system as authcookies can be stolen, even through other means than just a VRChat security hole, so extra steps need to be implemented to counteract against this risk:
authcookie's should be "dynamic" bound by default, which means they can be used from any IP address if at least one or multiple of many comparison factors are met: Country where the IP address is assigned in according to it's whois, AS number of the IP address, Cloudflare datacenter and/or location the traffic has passed through, HWID if it's from the VRChat client or User-Agent if it's from a browser. If too many comparison factors fail the check, the client needs to reauthenticate.
Once the client re-uses that same authcookie multiple times on different days with the same IP address, the authcookie turns into a "static" bound one which means it gets rejected when trying to use it from a different IP address, HWID/User-Agent, etc. than the one it is bound to or when at least one of the other comparison factors fail (other than the Cloudflare DC/location which should just be a fallback check for the dynamic bound option).
Additionally, authcookie information, the bound type and which IP address or IP addresses each authcookie was used and at exactly what timestamp it was used, should be exposed directly to the user, at least through the website, and the user should be given the option to expire a certain authcookie through a single click operation as well as set the expiration time and force reauthentication time for authcookies (expiration time = expire when not used within X days; reauth time = force reauthentication, even on valid authcookies).
Log In
Yukine
Since a few updates ago you can’t even rejoin the instance after the timeout popup anymore. Instead, you’re immediately sent to the error world, which forces you to restart VRC and log in again every time your IP changes.
I also seem to remember that VRC used to save logins for multiple IP addresses, so you didn’t have to re-enter your credentials when regularly switching between two IPs, though I’m not entirely sure if I’m remembering that correctly.
Aev
Merged in a post:
IP changes invalidates session token
ScruffyRuffles
I'm posting this under "Website Bug Reports" because It's a backend issue.
I really wish this didn't happen as my internet drops out every day and usually causes me to log back in.
No other social service does this so why should VRC?
System
These are all really good recommendations!
Auth Tokens being tied to IP is an old decision - it replaced an earlier behavior (Token expires after a relatively short time and cannot be renewed) which was also wildly inconvenient for the user - but we've always operated on the presumption that SOMEBODY is going to figure out how to steal tokens in client-land, _someday_, and when they do we need Additional Security Measures to shut that down.
IP is (as you've noted) a painfully, uh, broad security measure, and we could improve it dramatically by using more comprehensive and subtle angles to try to suss out a stolen token (and allow users to audit their own recent sessions). We've had similar discussions to this on our internal channels, and come to similar conclusions.
Fusl
System: With the recent implementation of instance join tokens and IPv6 becoming more popular this is becoming an even worse and more annoying issue. Is this still something that's in consideration and going to be implemented any time soon?