Page 1 of 2

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

Posted: Mon Mar 09, 2009 5:33 am
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

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

Posted: Mon Mar 09, 2009 5:38 am
by Benjamin
Do these intranets use static ip addresses?

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

Posted: Mon Mar 09, 2009 5:46 am
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...

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

Posted: Mon Mar 09, 2009 7:20 am
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.

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

Posted: Mon Mar 09, 2009 8:37 am
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

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

Posted: Mon Mar 09, 2009 9:20 am
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.

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

Posted: Mon Mar 09, 2009 5:37 pm
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

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

Posted: Mon Mar 09, 2009 5:52 pm
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.

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

Posted: Mon Mar 09, 2009 11:50 pm
by claes
No control at all, we would supply the link and the customer would put the link on their company intranet...

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

Posted: Tue Mar 10, 2009 12:16 am
by Benjamin
And give it to their friends too....

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

Posted: Tue Mar 10, 2009 12:20 am
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

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

Posted: Tue Mar 10, 2009 12:31 am
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.

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

Posted: Tue Mar 10, 2009 9:11 am
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?

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

Posted: Tue Mar 10, 2009 9:46 am
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.

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

Posted: Tue Mar 10, 2009 10:04 am
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...