Which I already pointed out. Paying somebody online to handle it.
2 Likes
In the past, ROBLOX made an update to the developer console that showed the server’s IP in the local log. Nearly immediately, users started DoSing servers, so it’s more than evident that delinquents, kiddies or not, have the tools they need to exploit this to the point where it becomes a serious inconvenience for others. I’d rather not wait around 'till hindsight to confirm that the same thing that happened with the server IP happens with this exploit.
4 Likes
wasn’t arguing whether it should be hidden or not in my last few comments. No need to continue to justify it to me.
I was just saying downloading a tool and dosing from your singular computer doesn’t work. You need a lot of effort to make it effective.
please don’t derail my thread then… there are good reasons ROBLOX doesn’t give game creators this information
8 Likes
We were always able to get the IP from the log files already.
(not to mention wireshark, looking at the RequestGame.ashx, …)
Unless you have a static IP (which only a select few have, most times even paying for it), sharing your IP is fine.
Fun how this thread got semi-derailed so easy, people are getting better at it
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.
4 Likes
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.
12 Likes
Then make a feature request; that’s not what this thread is for
3 Likes
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
8 Likes
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.
18 Likes
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.
10 Likes
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.
3 Likes
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.
Is it already fixed? le me le curious about le code
7 Likes
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.
2 Likes
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.
3 Likes