I'm working on a mobile game in Unity and I want to be able to identify my user without them logging in (so when they send data to the server I will know it's them).
In this specific case, the solution doesn't have to be data-loss proof (meaning it's not the end of the world if the user loses access to their data on the server), but I really want to avoid situations where users can access other users' data.
Here's what I thought of so far: When the user starts the game, a random ID is created and saved into PlayerPrefs. From there, the game takes that ID, adds to it the IP address of the user, and hashes it.
This hash is then sent to the server, and the server keeps in its data the hash as well as the IP address the request was sent from.
From now on, every request sent by the user to the server needs to be signed by the hash and come from this specific IP address. This means that if the user clears PlayerPrefs, uninstalls the game or changes device - they will lose access to their data on the server.
Do you think this will work, or is this impractical/insecure/inefficent?
Thanks in advance!
You can identify device by its unique ID. Works for Android and iOS. (Documentation)
string deviceID = SystemInfo.deviceUniqueIdentifier;
You cant take the IP because it changes a lot on a mobile phone, you need to stick to a random UUID generated when the app is installed, maybe you can add something like the MAC address of the Wifi adapter because that wont change... but if the user is on roaming or using the cellular network is a guess...
Remember that getting hardware identifiers are against the privacy procedures of many countries and companies, i'll stick to generating a random UUID for each app install
https://developer.android.com/training/articles/user-data-ids
Programmatically getting the MAC of an Android device
Related
I am doing research on an Eddystone project where the user would receive personal (and therefore to some extent confidential) information based on an Eddystone URL on their phones. There is no app involved, so the user would be directed to a webpage (based on the eddystone URL) which will display the info.
I am wondering regarding the security implications of this: Without an app, I guess the EID cannot be used - is this right (or is the EID accessible in the notification and can be passed to the destination website as a parameter)? Therefore, I suppose anyone with the name of the url could then access this information which would become a problem as you could scrap the data for every user using the service with a simple script that reads this website every now and then.
There may be a way around it if the url in the beacon can be changed on the fly to something like www.abc.com/some-random-number. That would work but it would mean that the beacon url must be updated frequently.
Does anyone know of any beacons that come with an API that would allow me to do this from a Windows machine (I know manufacturers have apps that can change beacon data but that is not an option because this should run without user intervention)? E.g. I was thinking of a USB beacon that can be accessed from a little piece of software on windows which changes the url.
Or does anyone have a better idea on how to deal with this?
Thanks,
Chris
If you are going to show the website visitors some personal and confidential information, I do think the only way to go about is to have some sort of login on the website. The ability to change randomly the URL address that the beacon broadcasts would not be helpful, as you need a way to connect the random website address to the individual accessing it. The EID is a way to distinguish which apps can receive specific beacon information - it does not check which individual is using the application. (And you can only utilize it with applications, at least for now).
I'm trying to figure out the best way to store data for a mobile chat program.
Basically I will be able to make a group with my friends and they should also see the same group I made.
I'm assuming the best way is to store the data locally on each phone, and then when someone sends a message, it goes to the network, and the network sends that data to each recipients local phone so that it updates the local data.
That way when people are opening up the application, the previous few messages are still visible, since the program will check local data storage.
Is this the proper way to create mobile chat? Or should there be no local storage of data?
The best way will be to store data locally and on the server as well. The reason are as follows
Local data is for the users and will allow the saving on data costs instead of the users always having to get their chat data online everytime they logon. My assumption is that you want to have offline messages the way that Whatsapp chat client has.
Server data is for your reference and also good practice in order to provide the user with data up to a certain point in history if they have lost their device and they login to another device.
I hope this helps and answers your question.
I've developed an app that allows users to upload some photos and share them on Facebook/Dropbox/Twitter etc. Recently it went live in the app store.
However, I'm having a problem now: a bot is creating accounts and uploading many photos on my server. I've temporarily disabled the app, but now I'm looking for an efficient way to prevent this bot from doing this.
The bot's ip address is changing very often so it's impossible to block the ip. He creates accounts with a very realistic name and email address so it's hard to find out which users are real and which are created by the bot.
I was thinking of using a captcha, but I'm not sure if my app will be rejected by Apple if I implement this. I'm preferably looking for a way so I can prevent him from doing his work and so I don't have to resend the app to Apple again.
Could anyone give me some advice on what I could possibly do?
Thanks!
This is how I solved a similar problem:
I implemented a token-generator, which generates a one-time token for every single data transfer with the server, so even one for login-data, sending a file etc. This token is generated by a secret algorithm and can be verified server side, since you know how you generate one.
After one token is used, put it in a temporary list for the next X minutes/hours/days (depending on how many data transfers your server can handle). When a user tries to send data with a used token (i.e. the token matches one in the "banned" list), you can be sure that someone's trying to spam you -> mark the account as "spammer" and decide what you wish to do.
The algorithm must produce a different token each time (the best way would be a one-way hash), but you have to assure specific "properties", with which you can proof its authenticity.
So one very simple example:
Your algorithm in the client is generating a number between 1000000000000000000000 and 99999999999999999999999, this number is then multiplied with 12456564 and incremented by 20349.
The server becomes a specific command and data, and the generated token. Now it checks, whether (number - 20349)%12456564 is 0. If it's 0, it was likely generated by your "secret" algorithm.
It's a very basic example but you get the idea…
Big question - my programmer is saying no but i want another opinion.
I have an iPhone app (in construction). It connects to a server.
The user logs in but too often when the app comes out of background another log-in (email address and Pin Number) is required rather than the simple pin number. Is there a way to keep the email address either 1/ in memory or 2/somewhere else on the phone.
I notice with the Facebook app (you may have heard of them) they just stay logged in regardless.
is this possible too for an individual player?
Thanks in advance
Joe
Of course you can. Just save the username in the NSUserDefaults and the pin in the keychain.
Then we the apps starts just check if those values are set and log the user in.
I'm wanting to allow users to create an account on my server automatically using their Game Center account. When my iOS app opens up it requires a connection and authentication with an XMPP server in order to communicate with the game server. I'm trying to find something in GKLocalPlayer that is private to a logged in device that I could use to create/validate a remote user login, but the only thing that seems to be unique to the player is their playerID which is fairly public.
I don't really want to use GameCenter for everything because then it partitions my user base to only iOS devices.
From developer.apple.com
... if your application connects to your own network services, you can use the player identifier on your service to save data there as well.
Since the player identifier isn't private, how sure can we be sure that this isn't being faked?
Everything in GKLocalPlayer can be faked. Same can be said for UIDevice.
A better strategy is to assign private session data to each device that connects and provide means to link device sessions to accounts via a verification email. Perhaps include the playerID to allow interaction with GameKit data, but not as a means of identification.
Looks like this is possible since iOS 7 using:
[localPlayer generateIdentityVerificationSignatureWithCompletionHandler]
https://developer.apple.com/library/ios/documentation/GameKit/Reference/GKLocalPlayer_Ref/Reference/Reference.html
I'm not sure that the player ID can be faked, but you could generate a key based on that along with the other unique ID that iOS users have: thier UDID. When a player successfully logs in to Game Center, generate a key based on the UDID. If it matches a stored value, you're golden. If not, it's likely the user on anther device since they've successfully logged in to game center. In that case, offer to add it. To prevent session hijacking, have the user confirm bew devices via email. This only works for iOS devices though, since it is tied to game center and UDID.
An alternative, which can handle other platforms as well, is to have your game contact your server on the first run and pull a generated unique ID from your server. Whenever your app reports a score (or anything else) you send your own ID. There are ways to encrypt that data, but I'm not even an amateur in that area. I know nothing of use there. (If you want, look into sending "API keys" along with your request or sending "salted hash"es. but I have no idea what that would do for you. I've heard of those before and suspect that that may help.)