search

timhutton / geofun

Exploring location-based fun
2 stars 0 forks source link

Prevent accidental cloning #17

Closed timhutton closed 7 years ago

timhutton commented 7 years ago

Reloading the tab or visiting the help page and returning causes an apparent clone of the user to be left on the map for five minutes.

Prob easiest solution is cookies to store the last known username.

rawles commented 7 years ago

I think cookies are a good plan here, but we can improve things further by incorporating @apgoucher's idea of hashing the IP address of the user (this assumes that IP address doesn't change (much) over a game). I plan to improve /name today by returning a name from a list on the server at position h mod l, where h is the (decimal) hash of the user's IP address concatenated with some salt, and l is the length of the name list. As long as the IP address doesn't change then neither will the name.

Cookies may be rejected by the client, so, in the case where storing the username as a cookie doesn't work and therefore no cookie exists for the client, we can fall back to this naming procedure. Of course, if a user chooses a name via the ? mechanism, that overrides any of this.

If you're happy with this I'll adapt /name today.

timhutton commented 7 years ago

I think we need a conversation about logging and IP addresses first. If we can't lose the creepy factor then the project has no future.

rawles commented 7 years ago

I don't understand what's creepy about this suggestion. We aren't logging the IP address of the user, but only using it in the generation of the name. Also, the source IP of the user is necessarily sent along with every request.

timhutton commented 7 years ago

I didn't mean that the suggestion is creepy but the whole game is in danger of being creepy. That was the word you used last night.

rawles commented 7 years ago

We could definitely easily implement a creepy game if we didn't give privacy much thought! It seems like you want to hold off implementation of this feature until we've better decided what we're doing with this data. Given a decent hash function and a secret salt, I don't see any way to recover the IP address from the username that's assigned, or even to confirm that a specific IP address is being used by a user who's been named, so I can't see any threat here.

timhutton commented 7 years ago

A question about Adam's IP address proposal. If a hacker gets the salt and a snapshot of usernames and locations then they can confirm with high probability that an IP address was connected to a geolocation. Is that correct or did I misunderstand it?

rawles commented 7 years ago

Say there are n usernames. Assuming the hash function distributes values evenly over its range.

The choice of suggested username breaks the space of IP addresses down into n subsets. If the hacker has the salt and a username, then they can determine that the user's IP address was from the same subset as the actual one.

For our purposes, I think n=256 would be reasonable (maybe even a bit cautious).

For example:

  1. The user has given no username and cookies are failing to persist. 256 names are read into an array called names.
  2. I send a request to the server with IP address 91.134.240.243 (the geofun server).
  3. The salt is "qwerty123". This salt can be per region, and changed between game sessions (for example, when there are no active users in an area).
  4. The SHA-256 sum of "91.134.240.243qwerty123" is "7676347c4ed1507c4447f1b6b8a1aa628ab0193b920d40f35553a5b727e456b4".
  5. We take the last two nybbles, 0xb4 = 180.
  6. Say names[180] == "Habiba". The user is named Habiba.

Doing a search of random IP addresses, it doesn't take long for another 'Habiba' to be found, for example 'chpc-vm01.campus.bath.ac.uk' (138.38.76.145). The hacker can't tell whether Habiba was using geofun or the Bath computer or any of the other (3706452992/ n) addresses.

If the hacker suspected use of a specific IP address, and wanted to confirm it with the salt, then they would have strong confirmation.

rawles commented 7 years ago

How about if the client sent a salted hash of their IP address? The question is then how to persist the salt, in which case we wouldn't need the IP address at all, because we've found a way to persist data between sessions (the original point of the cookie).

(Insert joke about salt having a long shelf life)

rawles commented 7 years ago

Maybe there's something else that doesn't change much about a user as they appear to the server, and can be used as an alternative? We should examine what else is sent in a typical request to the server.

apgoucher commented 7 years ago

On the client-side, you can use window.navigator.userAgent as a piece of relatively persistent information. Concatenating that with the IP address and hashing would be too large a search space (unlike the small space of 2^32 IP addresses) for 'creepy people' to brute-force.  

Sent: Wednesday, May 24, 2017 at 12:37 PM From: "Simon Rawles" notifications@github.com To: timhutton/geofun geofun@noreply.github.com Cc: apgoucher apgoucher@gmx.com, Mention mention@noreply.github.com Subject: Re: [timhutton/geofun] Prevent accidental cloning (#17)

Maybe there's something else that doesn't change much about a user as they appear to the server, and can be used as an alternative? We should examine what else is sent in a typical request to the server.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

 

rawles commented 7 years ago

In that case, let's amend the name/ endpoint to take a string sent by the client that is expected to be constant over the course of the game. The hash is then performed on the result of concatenating the IP address, the persistent string, and the salt.

@apgoucher, do you see any problem with the six-step process outlined in my comment above?

rawles commented 7 years ago

Why is this issue now closed? I think at some point we'll need to find a way of telling users apart from each other, even if its just to prevent cheating, like checking that a user doesn't appear to be moving too quickly over the map. It's possible to cheat very easily in the games, and at some point we'll want to try to do something about that other than just assuming nobody will want to cheat or upset a game in progress. For that and for future game ingredients that we haven't devised yet, these ideas are potentially valuable, so please don't draw a line under this idea.

rawles commented 7 years ago

I think I follow now. You've used the name server where cookies don't work on the client. We should try to use the peristent information that @apgoucher discussed above in calling the name/ endpoint, to overcome your concerns.

timhutton commented 7 years ago

Accidental cloning was the issue where simply reloading the page caused the assignment of a new username, which caused the appearance of two people on the map until one expired. We now cache the username (now using localStorage, not cookies) or retrieve from the name/ endpoint, so accidental cloning no longer occurs.

Issues of username collision (#24) and cheating are unresolved.