Reputation: 1191
I'm using "file_get_contents" in the following way:
(the script below is posted on, for example https://siteA.com/checkifvalid.php ...notice the URL is httpS)
<?php
//there is a login form on this URL and the entries put in the form are used to set the username & password variables below.
$username = "someusername";
$password = "somepassword";
$secretkey = "slkd89087235";
$yesorno = file_get_contents("httpS://siteB.com/checkdatabase.php?username=$username&password=$password&secretkey=$secretkey");
if ($yesorno == 'yes') {
//details are valid, so something
} else {
//details aren't valid, display they aren't valid
}
?>
The "checkdatabase.php" script gets the username & password using _GET and grabs the variables from the URL and then cross references those login details to see if they are valid or not. If they are, it echos "yes" if not, it echos "no".
The checkdatabase.php script is set to only run if both the username, password & secret key parameters have been passed, and then only if the secret key value that has been passed matches the secret key stored within that php script.
There will also be a limit to the number of times "http://siteA.com/checkifvalid.php" can be entered in a given span of time to prevent a type of "brute force" attack guessing user/pass combos.
My question is, how secure is the above method seeing as both URLs are using httpS?
Should I encrypt the values sent? Or is what is above secure already?
Upvotes: 1
Views: 2673
Reputation: 2887
[UPDATE] After a few comments, I've realised I read and answered your question too quickly. I'ev changed my mind.
Unless your attacker has access to the private SSL key, HTTPS is safe. If your server is ever compromised, then so is HTTPS until you generate a new key.
Second of all, if you're really going to use HTTP for this, you should use POST instead of GET.
1) The semantic reason: you're asking the other server to do something. That operation is not idempotent but the GET method is (at least in theory). As @Gumbo pointed out in the comments, you're only doing a check and not running any operations on the destination server so the comment about idempotence doesn't apply here.
2) Your password could show up in access logs. Even though different stacks seem to handle HTTPS loggin in different ways by default, you shouldn't take any chances and assume GET requests will end up in a log file somewhere.
You can use cURL to do the POST like this: PHP + curl, HTTP POST sample code?
Store and post an encrypted password Your master DB should not store plain text passwords. Instead, encrypt it before saving it, then encrypt the submitted user input before comparing.
Use a shared public key
Instead of posting a plain text usermame/password/secret, you could implement a shared key. This is essentially the same mechanism used by HTTPS. Using this method you could safely send this request over HTTP.
Read up on public-key cryptography, it's really easy to understand. Implement it using openssl_public_encrypt()
.
Read more about that last one here: Output of openssl_public_encrypt() and openssl_private_encrypt()
By far the simplest, setup the MysQL daemon on siteB to accept remote connections from siteA only, and query the siteB DB directly from siteA. This doesn't involve HTTP at all. Just makre sure your MySQL password is secure, restrict by IP, and don't store plain text passwords.
From Wikipedia:
[OAUTH] provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.
Here's the first article I found about writing your own: http://toys.lerdorf.com/archives/55-Writing-an-OAuth-Provider-Service.html
You might be better off using something like the OAUTH component in Zend Framework or something similar if that's the path you go down.
Upvotes: 3