This forum is in permanent archive mode. Our new active community can be found here.

Weekend coding

1151618202139

Comments

  • TOTP? Top of the Pops?
    Nope, Time based One Time Password
  • Is it dangerous to store the mysql password in a php script?
  • 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.
  • edited September 2013
    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?
    Post edited by Pegu on
  • edited September 2013
    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?
    Post edited by Linkigi(Link-ee-jee) on
  • edited September 2013
    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.
    Post edited by Pegu on
  • It looks like php isn't readable by default?
  • The Mysql server can be configured to accept connections from Localhost only.
  • 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.
  • edited September 2013
    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?
    Post edited by Pegu on
  • Can you explain what your goal is? Usually, the server is the only one to interact directly with the database.
  • edited September 2013
    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.
    Post edited by Pegu on
  • edited September 2013
    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.)

    Edit: WHERE statement does it.
    Post edited by Pegu on
  • 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.
  • edited September 2013
    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.
    Post edited by Linkigi(Link-ee-jee) on
  • Can't the user change the system time?
  • 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.
  • Can't the user change the system time?
    Yes, and that generally turns out to be a pain in the neck in a whole host of other ways due to the way it will interact with other apps on the phone.
  • edited September 2013
    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.
    Post edited by Anthony Heman on
  • 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.
  • edited September 2013
    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?
    Post edited by Pegu on
  • 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.
  • edited September 2013
    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.
    Post edited by Pegu on
  • edited September 2013
    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());
    Post edited by Pegu on
  • 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.
    image
  • Room number 3....
  • Secret treasure room.
Sign In or Register to comment.