Would the contents of the php script hit the client at some point? If it runs entirely server-side and you make sure they can't just grab the script with an HTTP request I think it would be okay.
I'm going to have an android application post to the script on the user's behalf. How do I make it impossible for the user to read the script? File permissions? Execute permission but not read permission?
I think that removing public read/write permissions will probably do it, but I am by no means an expert.
It might be wiser to ask: why does something the user is doing need access to a mysql password they shouldn't be allowed to see, and is there a better way to do it?
This is my first time doing php/mysql. Basically, I need a way to get data into and out of a localhost-only database. Also, how can I make sure I only get posts from my application. A secondary password in the post request doesn't seem secure.
Yes, and it is, but I'm making a php script to provide access outside localhost so that user data can be put in the database by the android application.
How does that help? Couldn't someone see the plaintext password in the post request? Or is it stupid to worry about network sniffing? Do I have to use https?
I'm creating a trial version of one of my paid apps. The app puts the phone's IMEI (unique identifier) along with the date of install into the database. The app checks the database to see if the trial has expired. Because the app cannot interact with the database directly, I'm creating a php script that handles post/get requests.
Also, my google-fu is failing and I can't figure out how to select a row by it's unique id and get the other column. (Get the datetime for the given imei.)
Errr, what? Why are you using mysql and php for what sounds like an Android app running more or less natively on the phone? Or am I just not understanding the basic architecture of your app here?
The app cannot communicate with the database directly because the database only allows connections from localhost. So I'm making a php script that allows database modification through http get/post. I think I need a database to properly check if the app trial has expired.
You could probably keep it all on the phone: set expiration day, sign by hashing it with the phone's MAC address and maybe something else, check against system time.
EDIT: that specifically is a bad signature scheme; you'd need some bit of information hidden to the user to make the hash unforgeable - but if you just sent some information and checked it against something set when the trial started, you could catch people trying to cheat.
The app cannot communicate with the database directly because the database only allows connections from localhost. So I'm making a php script that allows database modification through http get/post. I think I need a database to properly check if the app trial has expired.
So is the app running on the phone? Or is this phone app a front-end to a web-based app or some other server-based service? I'm not sure I follow exactly what you're trying to do here.
If the app is purely running on the phone and not connecting to any external service, I'd have to say mysql and php are entirely the wrong tools for the job. If it were my app, I'd use Sqlite (or whatever Android's equivalent would be, assuming it has one) and Java (Android's primary development language), or perhaps C/C++ (if the Java APIs don't cut it for some reason) to develop the app if this were the case.
I'm really not following what you're trying to do from this conversation, but if what you are trying to do is set up a php script that is accessed via https, and the user passes in a username and password (which you should encrypt anyway for the transition, in addition to the https encryption), that's pretty common stuff.
The script itself could have a mysql user and password to access some sub-set of the database. That script will not be able to be read by anyone if apache (or whatever) and file permissions are set properly. That's not really a php issue.
You shouldn't have any reason to be passing around mysql passwords or usernames anywhere. That should only take place server-side. None of that should be web-facing.
I want the data to be stored off the phone (no sqlite) so the user can't tamper with it to extend their trial. I don't want the user passing in a username and password, I just want a way to make sure that my app is the only thing posting to the php script that modifies my database.
I want the data to be stored off the phone (no sqlite) so the user can't tamper with it to extend their trial. I don't want the user passing in a username and password, I just want a way to make sure that my app is the only thing posting to the php script that modifies my database.
Okay, so the app is interfacing with some network-based service. That clarifies things a lot. Of course, you'll need to somehow secure the connection between your phone and the service to make sure the user can't tamper with that to extend their trial.
Unfortunately, I think the only way to properly secure the communications with the server is to have the phone app itself send some sort of encrypted credential token (a username or password of some sort, or any other token, that is embedded in the code but normally not user-visible) to authenticate itself with the server that handles trial registration. Otherwise, well, all it takes is someone with a wifi packet sniffer to figure out what the app is doing with the server and to forge stuff in order to extend your free trial.
Unfortunately, I think the only way to properly secure the communications with the server is to have the phone app itself send some sort of encrypted credential token (a username or password of some sort, or any other token, that is embedded in the code but normally not user-visible) to authenticate itself with the server that handles trial registration. Otherwise, well, all it takes is someone with a wifi packet sniffer to figure out what the app is doing with the server and to forge stuff in order to extend your free trial.
Yeah. So I was wondering how to go about that. If the app http-posted the token, it would be just as easy to sniff. So I gotta use https?
Unfortunately, I think the only way to properly secure the communications with the server is to have the phone app itself send some sort of encrypted credential token (a username or password of some sort, or any other token, that is embedded in the code but normally not user-visible) to authenticate itself with the server that handles trial registration. Otherwise, well, all it takes is someone with a wifi packet sniffer to figure out what the app is doing with the server and to forge stuff in order to extend your free trial.
Yeah. So I was wondering how to go about that. If the app http-posted the token, it would be just as easy to sniff. So I gotta use https?
Yep, https is your best bet here. You'll also need to implement some sort of authentication over https so that some 31337 h4x0r with a web browser doesn't start poking around your database either. Https will encrypt the contents of the communications but doesn't encrypt the source and target IP addresses and ports, so while someone with a sniffer won't be able to figure out just what you're sending, they'll figure out where you're sending it too and, without some form of authentication, they still may be able to bypass your protections just by connecting to your service with a regular ol' browser.
One possible solution to the authentication problem is to create a custom SSL certificate that your server recognizes and embed that certificate, probably in an encrypted format, within your app. When the app connects to your web service, it decrypts the certificate and sends it over https to your service to authenticate itself.
Mind you, having any sort of data stored on the user's phone makes it hypothetically possible to crack. Even if you encrypt the certificate, you'll need to store the decryption key somewhere in the code where it could potentially be reverse engineered out. The trick is to make things annoying enough so that only the most motivated crackers will bother going through the effort to bypass the trial period.
I've actually been thinking, and I don't think the user could extend the trial period very easily even if they just sent http requests to my script. It records the imei and the current date, and only allows one entry. Worst they could do is probably overload my database.
What's wrong with my code? $datetime = mysqli_query($con, "SELECT trial_start_date FROM trial WHERE imei='$imei'")->fetch_object("DateTime"); echo date("Y-m-d", $datetime->getTimestamp());
So, I decided to take a different approach than BSPs since they were not producing the levels I desired. Here is the output of the new method. I also added a room detector algorithm so I can work on themes for individual rooms as well as connect rooms together via passageways. Each tile below is labeled with the room it's a member of.
Comments
It might be wiser to ask: why does something the user is doing need access to a mysql password they shouldn't be allowed to see, and is there a better way to do it?
Edit: WHERE statement does it.
EDIT: that specifically is a bad signature scheme; you'd need some bit of information hidden to the user to make the hash unforgeable - but if you just sent some information and checked it against something set when the trial started, you could catch people trying to cheat.
If the app is purely running on the phone and not connecting to any external service, I'd have to say mysql and php are entirely the wrong tools for the job. If it were my app, I'd use Sqlite (or whatever Android's equivalent would be, assuming it has one) and Java (Android's primary development language), or perhaps C/C++ (if the Java APIs don't cut it for some reason) to develop the app if this were the case.
The script itself could have a mysql user and password to access some sub-set of the database. That script will not be able to be read by anyone if apache (or whatever) and file permissions are set properly. That's not really a php issue.
You shouldn't have any reason to be passing around mysql passwords or usernames anywhere. That should only take place server-side. None of that should be web-facing.
Unfortunately, I think the only way to properly secure the communications with the server is to have the phone app itself send some sort of encrypted credential token (a username or password of some sort, or any other token, that is embedded in the code but normally not user-visible) to authenticate itself with the server that handles trial registration. Otherwise, well, all it takes is someone with a wifi packet sniffer to figure out what the app is doing with the server and to forge stuff in order to extend your free trial.
One possible solution to the authentication problem is to create a custom SSL certificate that your server recognizes and embed that certificate, probably in an encrypted format, within your app. When the app connects to your web service, it decrypts the certificate and sends it over https to your service to authenticate itself.
Mind you, having any sort of data stored on the user's phone makes it hypothetically possible to crack. Even if you encrypt the certificate, you'll need to store the decryption key somewhere in the code where it could potentially be reverse engineered out. The trick is to make things annoying enough so that only the most motivated crackers will bother going through the effort to bypass the trial period.
$datetime = mysqli_query($con, "SELECT trial_start_date FROM trial WHERE imei='$imei'")->fetch_object("DateTime");echo date("Y-m-d", $datetime->getTimestamp());