I am needing help with single sign on. I have siteA.com that requires login credentials, once you are in SiteA.com you can do many things and one of them is access another application siteB.com. If you click on the option to go to this other application, the other application also has a login screen whose credentials are the same as siteA.com, so siteA.com and siteB.com have login screens of their own with the same credentials.
I am trying to make it a single sign on is there anyway I can remote login or pass credentials from siteA.com to siteB.com?
I am interested in:
Solved exactly same problem (actually also for 4 domains). The only solution I've came up with was, to include 3 hidden iframes on the 'Successful login page' and those iframes just load www.domain1.com/register_session.php, www.domain2.com/register_session.php, etc....
As a parameter for register_session.php I use 'sid' which contains session ID:
session_id($_GET['sid']);
session_start();
This is actually for keeping session alive on all those domains but the same would be for your case with cookies.
I think this could work but the problem is given the credentials, how can I make the script login to siteB.com?
I have done something which KIND of works...I copied the html of siteB.com and added that to hidden in siteA.com and at siteA.com made it do a double POST, one to siteA.com's login and another to siteB.com's login. This works only if the user has logged in to siteB.com lately, I think that logging in to siteB.com it sets a cookie to control access thats why doing the double POST allows you to fool the login system and as long as the correct credentials are provided it does a successful grab of login cookie, allowing you to login.
Store the user's information in a cookie( such as the user's id in the database ) then on the login page, look for that cookie. if it exists and is a valid user, go ahead and log them in.
When creating a cookie, you should be able to set it's domain to the domain of siteB.com so that siteB.com can see it. Simply create one cookie for each domain that needs to be able to read that cookie, and set acceptable expires settings on each cookie so that they either expire on session end or after x days.
Depending on how much security you need, you may need to put some kind of protection to prevent someone from simply creating their own cookie to get in freely (such as encryption)
I once had to tackle a similar problem. What I ended up doing was appending a hash to the URL query string of any link [or form] going from SiteA to SiteB, and visa versa. I used an MD5 hash of the user ID in the database for the value. On both sites, if that hash is present in $_GET, log the user in using a search for "MD5(user_id) = ?" instead of searching by username and password.
Edit: Note, this isn't a very secure solution - it just happened to be perfect for what I was trying to achieve. Please do keep security in mind. In my post above, an attacker could potentially determine that the token is an MD5 hash of an integer and start tinkering with it.
Related
I have build a php website, you can enter your login information and it safes a authentication cookie in your browser. After that a SESSION variable called 'user' is created and you can continue to the user specific pages. My question is, when the user switches to another page for example his settings should i check his login information again(hash auth_token and compare it to the value in db) or is it enough just to check isset($_SESSION['user'])
Sessions are stored on your server, and cannot be directly accessed by the visitor of your website.
This means that if you make sure that, if $_SESSION['user'] can only be set when the visitor enters valid credentials, you don't need to check the cookie every time. You simply rely on the session cookie. Checking it cannot hurt though, so why not do it?
Note that it is possible for a hacker to copy the cookies and pretend to be someone they are not. This is called "cookie spoofing" or session hijacking. Erasing important cookies when an user leaves the website can already defend against that quite well.
You're being somewhat vague about what you store in the "authentication cookie", but I think you're using random tokens which you store in the database and link to an user. That's a good idea. It is important to generate a new token every time an user logs in, and let tokens expire after a certain period if they're not used.
Normally When I design a site that allow users to login, I create session variables of the user info from the database and ensure that at least one of the session variable is available on each page of the site, else the user would be redirected to the login page like this:
if(!isset($_SESSION['username']))
{
header("Location:login.php");
}
But then I've been thinking lately, instead of using session variables to authenticate users, why not use the query string. My idea is to create a unique string which is based on some factors, like date(month, year, day) or access time(day, hour) or ip address, and maybe hash it using md5 so the url might look like this
://mysite.com/dashboard?auth=12jsdnnau819wiskj3jdnck23ksj12j3.
So now I can easily logout a user if he has not accessed the site for more than one hour or more than one day. But I do not know if this is a good idea, that is why i am here, to seek for advice on a better way to go. Thanks all.
Because URLs:
Leak easily
Get bookmarked
Don't carry their data over automatically when the user opens a new tab and navigates back to the site
and because nothing is stopping you from storing the same data in a session and using that to easily logout a user so it doesn't even add the one benefit you highlight.
Don't do this.
Do you remember the days when PHP session ID could be stored in the URL, and you would have URLs that look like: index.php?PHPSESSID=.... ?
We have moved away from this to more secure implementations, user friendly URLs, etc.
Just as a simple example of what can go wrong: A web crawler can crawl your website, and if reaching the admin panel with a properly authenticated URL (as you described), it could become publicly available to ... anyone.
So ... don't reinvent the wheel.
I can think of a few reasons not to do this:
The hashed request parameter is publicly visible. This means anyone using that url will be considered an authenticated user.
As I can see, the token is per user, so all requests using this token will be done on behalf the same user. If you share a url, anyone using that url will impersonate the same user, and have all the access rights granted to that user.
Other answers have mentioned that the urls can easly leak, or be bookmarked. In addition to their points, once the token expires, the url may become broken, if you trigger a login or other authentication redirect mechanism.
A pure technical drawback of your idea is also this: you need to persist the token when navigating across different pages in your app
The HTTP Session has been designed to serve this purpose and at the same time be safe enough. The application session length can be tuned so that it matches your requirement. I recommend you to get familiar on how HTTP sessions work and how to tune your session expiration policy, rather than compromise your application's security
So I have the example-google.php script working, after loging in it throws the default user string has logged in. But my question is how does this protect anything?
Lets say I have //127.0.0.1/example-google.php and I added a href to //127.0.0.1/abc.php after the login is successful.
Well what keeps someone from just typing 127.0.0.1/abc.php? granted I could use $_SESSION to verify that "someone" logged in. But is that going to be enough? Is there a way to re-verify that the user that is trying to access abc.php is truely logged in when thrown from the other page?
Generally, the idea is that you use the session store, indeed.
For example, in my site I have a OpenID login using Steam Community. When a user logs in, after the mode / validate checks etc. from the LightOpenID example, I save their unique identifier in the session store (in this case a SteamID, in your case an email address presumably), then can just use this freely for subsequent requests.
As the session store is server-side, a user cannot impersonate another one without gaining their session cookie (session hijacking is another topic that someone else can go into much more detail on, but I'll give it a shot if requested), but most attacks will be defeated by also storing and validating the requesting IP address.
I keep a couple of mysql tables (one for sessions and one for user information) and store session information in the session table and include a reference to the users table. When a user successfully logs in with their OID provider they are sent back to my site with the confirmation from the provider. I keep track of my user from then on via their session id.
I wipe the session if they choose to log out, but maintain the user info for comments/posts on the site to track who said what.
I actually put a link to "?login={service}" which sends the request to the OID provider and redirects back to that page and on return from the provider it takes the successful login and stores the appropriate information and redirects the user back to the original page where they clicked the "login" button for whichever {service}. You only display the "members only" content if they are verified via OID. You don't create a standard HTML page at abc.php without any sort of way to confirm ID and I think the header redirect is important because it cleans up the URL displayed in the address.
In my login code on my website, if the password & username are correct, I set a cookie to keep the user logged in.
I just heard from a user that he doesn't accept cookies automatically through his browser, and that that prevents him from logging in. That rhe cookie is not set.
Is there an easy way to counter that?
Tell me if you need the code I use.
It is possible to get this to work but often a real pain if you're using complex javascript/ajax.
In short, instead of storing the session id in a cookie, you embed it at the end of every link.
so
http://example.com/somepage.php
becomes
http://example.com/somepage.php?SessionId=ABC123
Unfortunately, while PHP can do this for you in some cases, it doesn't help with links you build yourself in javascript - and it only takes clicking a single link without the id to effectively log the user out
See this page for more information
As mentioned by Quentin in the comments, if you're not using a cookie to identify the browser which created the session, it's possible that sharing a link would share the session. This could be mitigated but not prevented by checking IP address/user agent but this would likely fail in large corporate environments with NAT and standard browsers
I'm developing a website in PHP and I'm trying to use OpenID for log-in mechanism. I want a behaviour similar to StackOverflow's. By that, I mean whenever I open stackoverflow, I'm already signed in. I found two related questions on StackOverflow:
OpenId + remember me / staying logged in
Sign in with Twitter, and stay signed in (PHP)
I understand that I should sign in the user and if this is his/her first time, I should sign up the user and set a cookie in his/her system. However what I want to know is what should I store in the cookie? Username/password combination? That seems like a security issue. And the other question is where should I check for the cookie? I would appreciate a simple tutorial/code sample. Thank you.
This is basic web app session management with cookies and OpenID doesn't make a difference here at first.
No, absolutely do not store the username and password in the cookie. Cookies act as "bearer tokens", meaning whoever has the cookie gets in. The best thing to store in a cookie is an unguessable and arbitrary key that you can use to look up real information in a table in your application. So, the user shows up with a cookie of "myappsession" and a value of "234871nb341adf" tied to your domain. Your app would then look up the value of "234871nb341adf" in a local data store and see if it's tied to a valid user. You'd be best served to also check how long ago that user was there and whatnot. If it's a valid session and it's within your time and usage limits, the user is logged in automatically.
For extra paranoia from the RP side, you can make use of the checkid_immediate mode of OpenID to make a background call to see if the user is still logged in to their IdP. If they're not, then you at least know which provider to try to send them to for re-validation and can provide a better user experience.
If you want your site to be really secure, you should do all of your sessions over HTTPS and tag your cookies as both "Secure" and "HTTPOnly", which is documented on the setcookie function manual page: http://php.net/manual/en/function.setcookie.php