Script that gets players' IP addresses

I think it’s due to the law. An IP can be used to get someone’s location and developers should not be able to locate kids playing their games. I believe this is a part of COPPA compliance.

On top of this, devs don’t need this info whatsoever.


rip ability to block skiddies using multiple accounts to annoy me and other devs in our projects, cause banning their accounts don’t do a damn thing (and there’s a mute limit in chat). I still think you guys should give us a unique client hash which is generated and stored in registry or something, regardless if people change it or not. It’s not location based, and most of the kiddies only know how to run a batch file, not the ins and outs.


Then make a feature request; that’s not what this thread is for

1 Like

I think a neat way to deal with actual in game ip banning is something like roblox generates a random string that is associated with that ip address, then when they join the game it has like “ip-id” property or something, then be able to check for that, but no way to reverse the random string back to IP

1 Like

That seems like a really negative reason to implement a feature; for dev-based banning.

ROBLOX has moderation and you can report inappropriate users. If you don’t want somebody following you, block them or set your following to friends only.

Pro tip: People annoy you to get a reaction/attention out of you. Stop giving a reaction and they stop having fun, thus leaving you alone.

1 Like

That is neither efficient nor is it guaranteed to get results.


This will be fixed tonight.

The issue with giving out IP’s in encrypted form is that it assumes the algorithm/key will permanently remain a secret. Once the algorithm details are out, you can quickly find all 4 billion IP/encoding pairs.

A device identifier also has issues. For example, if it is in the lua api, it will be bypassed easily. Next, attackers will attempt to find targeted users’ device id’s in order to spoof them. At a minimum, device id’s would need to be place-specific and assumed to be spoofable/invalid.

It isn’t a bad idea though. It could give valuable, non-exploit data as well – for example the percentage of users that play your game on both mobile and desktop.


I don’t know a lot about hashing, but it seems that would anonymize the data sufficiently. Are there issues with hashed IPs?

Hashed IP is IP + 2 seconds of processing.

1 Like

I’ll admit I don’t know much about this topic, but what if ROBLOX internally stored values?

Not so much of a hash, but a GUID generated when the IP is first seen.
Seems like IP addresses are something that ROBLOX would already have?

1 Like

If you want a hash as a unique identifier that’s only ever the same for the same IP, then you need a hash that is at least just as long as the IP. That means every IP results in a unique hash value, so you can still just calculate the hash of 4 billion IPs quite quickly and then use that as lookup to get the IP back (if you find out the hashing method).

The only way to prevent that is to take a hash shorter than the IP, but that means you get collisions (multiple IPs will result in the same hash), and furthermore even then you can still find the X (where X a small number) IP addresses that could coincide with that hash. The shorter you make it, the higher X will be for each hash value, but you’ll also get more collisions at the same time.

So all in all it’s not a really desirable approach, if you can’t assume the way of hashing will always be secret.

Ayy a thread about me :sunglasses:


Is it already fixed? le me le curious about le code


I believe this is called a rainbow table. It’s essentially a table that lets one look up Hash -> Pre-hash. There are methods to prevent this…

Why would that be? I don’t know a whole lot about cryptography and security, but as far as I’m aware the standard way of preventing rainbow table attacks is a salt. That is, a (usually, and best) randomly generated value is combined with the data to be hashed (usually a password). This is the opposite of what you’re suggesting.

Making a rainbow table would be extremely effective if ROBLOX shortened what they are hashing without salts, which seems to be what you are suggesting. If ROBLOX will be doing that, they might as well just hand developers truncated IP addresses without hashing them in the first place.

If the salt+hash computation is done only on ROBLOX servers with code not released to the public, assuming no breaches, then it should be possible to create a very safe unique identifier hash using the same methods used to make a password hash. That is, expensive hashing functions to prevent brute-forcing and salts to prevent rainbow table attacks.

There’s still a flaw though: I’d be able to know the hash for my own IP address, so it would still be possible to create a rainbow table, it would just take a long time and a lot of collaboration to cover many IP addresses.

Overall I would not suggest implementing a sort of unique hash IP address thing. Barring algorithm breaches, it seems fairly secure, but even if it is secure, we don’t need this information! Banning by IP address, for example, could lead to players who get assigned that IP address in the future being unable to play. The concept of an IP address as a unique identifier for a person falls apart even more when you consider players playing over a mobile ‘data’ connection or households with multiple players.

The other use of IPs would be geolocation, but that can’t be done using hashed IPs anyway. Given that, I don’t see any use of hashed IPs (or any other unique identifier that maps to IPs) that should be encouraged.


No, it’s not the opposite of what I’m suggesting. I was saying that if you know the method (that is, including how/what salt is involved, because when I say “method” that is part of it), you can construct the table in feasible amount of time (I’d reckon, but I haven’t tried it).

You’re right, “the only way” should be “a relatively effective way” in the second paragraph of my post. Although the main focus of my argument was how you have interplay between chance of collision and level of security depending on hash length.

And yeah definitely hashing the IP does not seem like a good approach to create “anonymous” player identifiers, this is what I was trying to convey also.

IMO, the most realistic solution would be the one where the internals are never provided to the developer. Eg, where the developer never sees the IP address or an encoded/encrypted/hashed/etc… version of the IP address.

The developer would only be able to add the IP to a set of IP addresses. They would only know if a user joins with one of these IP addresses – therefore it is less than 100% secure. Ideally the developer would not be able to gain any information about the user’s IP address. To reduce this attack, there would be a minimum and maximum duration instead of the direct ability to remove keys.

In the extreme, a user could learn his ip address, develop a game, only add that one ip to the set, and then change IP using normal means. They could then determine if any other user joins with that IP – giving the exact ip address and userid of a random user. For games popular games, where a dev also lives in an area with many players, this could be a feasible attack.

To avoid this, the logic could potentially be done 100% on the server, or in a lua vm that has severely restricted access. At that point, a user could disclose information on the forums or etc… that would allow the developer to determine the ip address through the same method.

This system could also allow user-id based whitelisting, which could have duration or add/removed based logic. This would allow known-good users, admins, creators, etc… to join the game without being kicked.

He was storing thousands of user’s IPs in a discord server. I don’t know why this hasn’t been brought up yet.

He was also tracing some of the addresses he amassed (illegal!?!), and black mailing people with where they lived.

Why has this not been mentioned yet.

Because this is a bug report about a script that gets player’s IP addresses, so that’d be somewhat off-topic

1 Like

I’d argue that it’s still relevant because this elaborates on how the exploit was actually used

This is REALLY Late, but it’s patched now so…

  if Child:IsA("NetworkServer") then 
      Child.IncommingConnection:Connect(function(IP, Replicator)