"remotely" authenticating users

[rayman0487]

Hi all, I've been working on a new php application that my users will host on their own domains. I also have my company domain. What I'm trying to do is create a php file that will verify a value from MySQL DB on my company domain. All I'm waiting is to get a date from company domain MySQL.

 

So, I have user.com/Program AND developer.com/  Developer.com has a DB named Allowed_User that store CompID and AuthDate. I'm trying to send CompID from User.com and return AuthDate from Developer.com. Basically, when their pay the fees, AuthDate is set to the 15th of next month. The program will then compare the AuthDate to the current date and either allow the script to continue or it will exit saying they haven't paid

 

Not having any experience with this sort of thing, is there a better route to go? I was planning on verifying this date every time someone logs in, so atleast once per day/user/location.

 

Any suggestions on how to do is would be greatly appreciated.

 

Thanks,

Ray

[Psycho]

What you are asking is simple. Just use file_get_contents() with a user back to your site passing an optional parameter for the CompID:

$auth = file_get_contents('http://www.developersite.com/authenticate.php?CompID=123');

 

Then set up the page on your site to take the CompID from teh $_GET array, perform the validation, and then return a 1 or 0 (i.e. true/false).

 

however, there is one big problem here. This could easily be circumvented by the user. They could easily find the place in the code that makes the check and simply circumvent it or hard code it to assume a true response is received. I don't have a good solution other than using some obfuscation - which would never be foolproof. You would need to do something so the user can't make the application operational by just commenting out or circumventing some lines of code. The only thing that comes to mind is some king of encryption process that would require them to get a new key once a month. But, this would lead to more complexity and if someone was really determined they could circumvent it anyway if they want to put forth the time and effort.

[jcbones]

I agree with the Psycho, but would add that users who buy software (for end use), most likely, would not have the ability to reverse engineer it.  Not to say you should worry about it (or code for it), just that not being able to make it 100% foolproof shouldn't stop you.

[jcanker]

Require allow_url_include to be enabled on the client server by way of your license agreement.  Be sure to log connections in your own db and check periodically which clients are not showing up there.  Don't forget to include in your license agreement that they don't have the right to alter the code.

 

Use a require_once to a file on your webserver

Inside that require_once create your check and create an obtuse $_SESSION variable to hold the logged status. 

For good measure, include an important function in that include which would otherwise be in the user's local php page.  This will prevent them from just commenting/deleting your require_once.

 

Between those, you won't make it locked perfectly, but you can obfusicate it enough to prevent all but the most intent users.  Double checking who *should* be dialing home to your DB and who isn't would help identify abusers. 

 

[xyph]

You can't include remote PHP code, unless it's delivered in plain text, and then eval()'d.

 

Allowing your script to eval text from an external server can be dangerous.

[Psycho]

I agree with the Psycho, but would add that users who buy software (for end use), most likely, would not have the ability to reverse engineer it.  Not to say you should worry about it (or code for it), just that not being able to make it 100% foolproof shouldn't stop you.

 

This isn't a desktop app that is installed with a point and click dialog, it is a web-based app that requires someone with knowledge to set up a web server, database, etc. If you want to protect your intellectual property then just host it as a SaaS application. It would cost more for hosting fees and such, but that gives you more leverage for a higher price point since there will be zero IT/maintenance costs for the end users. In addition, it means you will not have to worry about the most complicated part of support - the back end issues.

[jstrike]

If you're distributing it, and it's worth money to you to prevent it being ripped off, then obfuscate it. Professionally. Use Zend Guard or something like ionCube to lock it down. Then have it make a call to your home server to check if its license is up to date. file_get_contents() is as good as anything else for that purpose, but without obfuscating and encrypting your code, it's worthless.

 

Also, sending eval() code over the wire isn't just pointless - since anyone can intercept it. It's introducing a giant security hole in your code that makes it, frankly, extraordinarily dangerous for an end user to run unwittingly. Because anyone can alter what goes into that stream and take control of the user's system. And if you crypt it somehow, someone will find the key and crack it in a day. Don't sacrifice user security for profit; you'll be counting the seconds to a lawsuit. Anyway, a little leg work will find you a better way to license, package and distribute your code without putting anyone at risk.

[rayman0487]

All good suggestions and advice, thank you all. I'm currently hosting this myself for one company that I'm working with - I'm using them as my debug team - so I'm not charging them. But, I'm in talks with another company and I'm trying to figure out my pricing model. I was thinking of going with a SaaS type setup where I'd host it on my servers and charge them a little more - since they are not having to do any configuration/hosting. However, the owner of this other company is a little on the 'crazy' side and thinks that since it's going to have his data he wants it on his Go Daddy account (no comment there), so I was trying to think of a way to authorize his license as mentioned.

 

I figured it would be a security issue and after seeing there really isn't a good way to do it, I'm thinking that hosting it myself would be the most ideal situation. This is my first web based application that I'll be deploying publicly, ie not on an internal network. I've deployed .NET exe programs and those are a little simply to authenticate.

 

Anyhow, thank you everyone for your inputs. I'll be toying with this next week and if I have any other questions, I'll post here, but as of now I think I'm going to get my own VPS and host it myself. On that note though, what would be most ideal? 1 Large database for all users (i.e. Comp1 and Comp2) or individual MySQL Databases for each company? I'm thinking creating a users database that stores every single user and there is a field that ties them a particular company DB.

 

-Ray

[jstrike]

One thing you could do would be to host the PHP platform yourself, and let each user host their own MySQL server. That way they can keep the data and you can keep the code... just keep a master list of which user/group connects to which database after they login, and connect remotely (with SSL)...

[MMDE]

If you want to earn money, then often a lot of companies earn more money on giving support for the service than what the customers pay for the service. What I mean is, start-up cost, special customization, pre-paid support for x hours, pay-when-needed support. etc I don't know exactly what your software is like, but usually it is a good idea to be in control of it yourself. I guess if it's a complicated piece of software and people might need help with it, sometimes letting people have control over it themselves is a good idea (because they will need help with it)!

 

What I am suggesting is looking into what kind of customer support you can offer to earn extra money. I personally don't think you should charge for a lot of different things, because that's just annoying and painful and people would try to avoid you, but if it's kept at a reasonable level and the customer feel like they get what they pay for and maybe a bit more, then you both win. Sure you also need to keep up with competition.

 

I hope this gave you some good ideas, and not bad.

 

About access to the database, uhm, depends on how much control the user have. You don't want the other companies to be affected by the sloppiness of another.

[Psycho]

. . .  what would be most ideal? 1 Large database for all users (i.e. Comp1 and Comp2) or individual MySQL Databases for each company? I'm thinking creating a users database that stores every single user and there is a field that ties them a particular company DB.

 

One single database would be the best option for scalability and probably performance. It would also be much easier to maintain. For example, if you make updates to the application that requires changes to tables, you only need to make those changes once instead of multiple times for each database. What one customer does should not have any impact on what another customer does. That assumes you have taken the necessary precautions against SQL injection and other DB security threats. Also, you should make sure EVERY query includes an appropriate WHERE condition to only get information for the user's company.

[xyph]

Something about using a single database account that has access to all of your client's data scares me, even with injection precautions.

 

I'd probably do a database for each client, each with it's own user, but I'm slightly paranoid.