An unorthodox authorization - should I even consider it...?
Moderator: General Moderators
An unorthodox authorization - should I even consider it...?
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
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...?
Do these intranets use static ip addresses?
Re: An unorthodox authorization - should I even consider it...?
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...
but it probably depends from customer to customer. Maybe solution can be to offer this solution only to those customers that have fixed IPs...
- 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...?
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...?
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
):
"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
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
"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
- 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...?
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:
Note the s -character in https://. And then, yoursite.com login.php:
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:
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
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.
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');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']);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)Code: Select all
if ($_GET['challenge'] = hash($secret . $_GET['userid']))
// valid, log userid inPlease 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...?
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
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
- 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...?
Do you have any control over the intranet?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
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...?
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...?
And give it to their friends too....
Re: An unorthodox authorization - should I even consider it...?
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
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...?
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.
- 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...?
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...?
Oh dear.kaisellgren wrote: For instance, using md5() for the hash would break everything, because it would be ridiculously easy to figure out the $secret.
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.
- 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...?
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...Mordred wrote:Userid: 1
Challenge: 877056fecaea5afb6b00d59cc9006431 = MD5(secret .. "1")
Secret = ?