An unorthodox authorization - should I even consider it...?

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

claes
Forum Newbie
Posts: 6
Joined: Mon Mar 09, 2009 5:04 am

An unorthodox authorization - should I even consider it...?

Post by claes »

Hi all,
My next project includes a "normal", secure login over SSL and remembering the user as authenticated in a session. Besides this login, our product mgmnt wants some customers to just follow a "direct" link from the customer's intranet, without having to enter login and password, e.g.
https://ourDomain.com/validate.php?c=someCustomerSpecificStringToIdentifyThem

Is there any way of obtaining this with a reasonable level of security, or should I not even consider it...?

Thanks!
/Claes
User avatar
Benjamin
Site Administrator
Posts: 6935
Joined: Sun May 19, 2002 10:24 pm

Re: An unorthodox authorization - should I even consider it...?

Post by Benjamin »

Do these intranets use static ip addresses?
claes
Forum Newbie
Posts: 6
Joined: Mon Mar 09, 2009 5:04 am

Re: An unorthodox authorization - should I even consider it...?

Post by claes »

Good question,
but it probably depends from customer to customer. Maybe solution can be to offer this solution only to those customers that have fixed IPs...
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: An unorthodox authorization - should I even consider it...?

Post by kaisellgren »

Did I understand correctly, the customer may login at intranet and then easily go to yourdomain.com through one link and stay authenticated? If so, then you could just setup the session to the yourdomain.com in addition to the intranet. How? There are a couple of ways. For instance, prior to login, use AJAX to submit the login credentials to yourdomain.com with HTTPS. Also, one common method is to use HTTPS redirects.
claes
Forum Newbie
Posts: 6
Joined: Mon Mar 09, 2009 5:04 am

Re: An unorthodox authorization - should I even consider it...?

Post by claes »

Hi kaisellgren,
yes, right on the spot. The https://ourDomain.com/validate.php?c=someCustomerSpecificStringToIdentifyThem link would only reside inside of the customer's intranet.
I have never done anything with Ajax, but your 2nd tip sounds interesting. Do you mean the htaccess file and write something like (in plain english :D ):

"If queryString = 'c=someCustomerSpecificStringToIdentifyThem' and referrer = 'www.companyA.com' => continue to setSession.php"

If this is (kind of) what you meant, couldn't that be performed in php instead? What is the benefit of doing it in htaccess? I would have to have one rewrite rule for each customer, or...? :?

Thanks!
/Claes
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: An unorthodox authorization - should I even consider it...?

Post by kaisellgren »

Forget .htaccess.

There are two situations from what I can think of: prelogging and postlogging.

Prelogging
Prior to login process, instead of only submitting the data to the intranet .php script, you also submit the same data to the yourdomain.com. Here's a sample Pseudo PHP login script code for the intranet:

Code: Select all

$username = $_POST['username'];
$password = $_POST['password'];
if account not exists $username and $password
 exit;
// create the session since the details were ok..
header('location: https://yoursite.com/login.php?u='.$username.'&p='.$password.'&intranet=ip_to_intranet_or_domain_wtvr');
Note the s -character in https://. And then, yoursite.com login.php:

Code: Select all

$username = $_GET['username'];
$password = $_GET['password'];
if account not exists $username and $password
 exit;
// create the session since the details were ok.. and then redirect BACK to intranet
header('location: '.$_GET['intranet']);
That is a simple demonstration. Very simple. You could send an actual POST request instead of GET and also, that code is vulnerable. The header redirections use the variables directly, you must filter the variables first.

Postlogging
This one happens after the login process. For instance, the user logged in the intranet long ago, so you do not have the user credentials anymore, but you have the identifier (for instance). One way could be to generate secret key, which is the same for all intranets (and yourdomain.com). Then do:

Code: Select all

$challenge = hash($secret . $userid)
After that, you could just send it over HTTPS to yourdomain.com/login.php?challenge=$challenge&userid=$userid and the login.php will then check that

Code: Select all

if ($_GET['challenge'] = hash($secret . $_GET['userid']))
 // valid, log userid in
Since the secret key is only known by the intranet/yourdomain.com, no one else can figure it out and make sessions.

Please note. I have been talking simplistically. You have to implement everything carefully. For instance, using md5() for the hash would break everything, because it would be ridiculously easy to figure out the $secret.

I would recommend the former approach. The ladder involves more risks.
claes
Forum Newbie
Posts: 6
Joined: Mon Mar 09, 2009 5:04 am

Re: An unorthodox authorization - should I even consider it...?

Post by claes »

Thanks for the suggestions!
Unfortunately prelogging is out of the question. I might have been a little unclear in my description, but we wont have any control or have anything to do with logging in to the customer's intranet. The only thing we would be able to do is to provide an https link that the customer then puts on a page on their company intranet...

Regarding postlogging, we won't have access to any identifier (meaning the userId, for example?). No matter who is accessing our link on the customer's intranet, their authorization and "profile" should be the same. We provide "per company"-specific information.
My biggest concern is that the url with the query string somehow gets intercepted despite https. Because if it does, no matter the $secret, the interceptor would be authenticated and able to see customer-specific data.

/Claes
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: An unorthodox authorization - should I even consider it...?

Post by kaisellgren »

claes wrote:Thanks for the suggestions!
Unfortunately prelogging is out of the question. I might have been a little unclear in my description, but we wont have any control or have anything to do with logging in to the customer's intranet. The only thing we would be able to do is to provide an https link that the customer then puts on a page on their company intranet...

Regarding postlogging, we won't have access to any identifier (meaning the userId, for example?). No matter who is accessing our link on the customer's intranet, their authorization and "profile" should be the same. We provide "per company"-specific information.
My biggest concern is that the url with the query string somehow gets intercepted despite https. Because if it does, no matter the $secret, the interceptor would be authenticated and able to see customer-specific data.

/Claes
Do you have any control over the intranet?

If putting (or asking to put) a link is all you can do, then you should forget this login idea, because it requires interaction between the two nodes.
claes
Forum Newbie
Posts: 6
Joined: Mon Mar 09, 2009 5:04 am

Re: An unorthodox authorization - should I even consider it...?

Post by claes »

No control at all, we would supply the link and the customer would put the link on their company intranet...
User avatar
Benjamin
Site Administrator
Posts: 6935
Joined: Sun May 19, 2002 10:24 pm

Re: An unorthodox authorization - should I even consider it...?

Post by Benjamin »

And give it to their friends too....
claes
Forum Newbie
Posts: 6
Joined: Mon Mar 09, 2009 5:04 am

Re: An unorthodox authorization - should I even consider it...?

Post by claes »

Yes, but I don't think our customers would want to spread that info...
Perhaps I can find a solution which also checks the query string together with the IP address range of the customer's intranet...?

/Claes
User avatar
Benjamin
Site Administrator
Posts: 6935
Joined: Sun May 19, 2002 10:24 pm

Re: An unorthodox authorization - should I even consider it...?

Post by Benjamin »

If I coudn't tie it to an IP I wouldn't do it. Sooner or later someone would get the url and wreak havoc.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: An unorthodox authorization - should I even consider it...?

Post by kaisellgren »

I agree. Having a link that is not constructed safely (e.g. using a hash and a secret shared by two systems where the secret is unknown to others) and is not tied to any specific IP, is definitely not a good idea. Even thought you could tie it to an IP, what about Wi-Fi or some other networks where there are numerous people using the same IP?
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Re: An unorthodox authorization - should I even consider it...?

Post by Mordred »

kaisellgren wrote: For instance, using md5() for the hash would break everything, because it would be ridiculously easy to figure out the $secret.
Oh dear.

Userid: 1
Challenge: 877056fecaea5afb6b00d59cc9006431 = MD5(secret .. "1")
Secret = ?

---
Apart from this, I agree with what's said. You must ask for control over the code that generates the link, otherwise it will leak. Locking by referer won't do, it's fake-able. Locking by IP is fine, up to the point where someone gains control over one of the clients, including stupid stuff like XSRF.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: An unorthodox authorization - should I even consider it...?

Post by kaisellgren »

Mordred wrote:Userid: 1
Challenge: 877056fecaea5afb6b00d59cc9006431 = MD5(secret .. "1")
Secret = ?
Are you asking me to figure it out? And what do I get for that? Cookies? Or perhaps you send me flowers? Ok, I will do it when I get two or more new GPUs and some good ASM CUDA SLi cracker tool plus some holiday time...
Post Reply