Is it possible to check (using PHP or Javascript) if a user is logged into his/her account?
I need the name, email and photo.
It is not possible unless you're twitter.com, cookies are only passed to the domain they're for (or a parent domain, depending on how they're set), for security reasons.
Imagine if you could do this, do you want any web site you visiting knowing your an SO member, your gmail login, your....you see my point, it would be a huge privacy breach, as well as a security one since you could steal a user's session on many sites.
You can't do it by reading the cookies. Each cookie is tied to a domain, and can only be read from that domain.
You can, however, use Twitter's REST API to get information about a user. Combining this with OAuth should let you make sure that the user actually owns that account, and let the user log in if they need to. Refer to Twitter's documentation for details.
Related
I stumbled upon a method of securing user accounts which basically automates the user's password. From a user perspective I think it's much better than a conventional passwords and I think also from a security perspective it would be preferred over conventional passwords.
I'm developing a PHP based application that will be a companion app for a video game. Which is only relevant to explain the link I'm going to post for others to test the method I'm proposing. It involves multiple files so posting a link and asking people to try the method is the best "explanation" that I can provide but I will brief the method also.
The user provides an email address to create an account. The program generates an email with a link in it. When the user follows the link in their email, an access cookie is set on their device.
The user is given control over the cookies which grant access to their account. The user can revoke access cookies and set new access cookies on other devices.
The program also compares access cookies and fingerprints, and will revoke access cookies when the device's access cookie and fingerprint don't match with the database.
Revoking a cookie has two effects. The database connection between the device and the account is updated so the revoked cookie no longer provides access to any accounts, and the revoked cookie is subsequently unset from any devices it's found on.
Included is a picture of the user account page which shows the Access List, the list of cookies that currently grant access to this user account. The user can revoke access from this page or send another email to set a cookie on another device. The image demonstrates an account which has two access cookies granting access to the account from two devices.
The user or program can revoke all access cookies and still the user can send an email to the address associated with their account and easily regain access to their account.
Depending on the device fingerprinting method, the user will need to reset cookies on devices after browser updates or changing plugins.
On the positive, they don't need another password. Passwords are commonly referred to as the "weak" link in an account and this method essentially automates, refreshes and maintains the integrity of passwords through cookies and an associated email account. As I mentioned in the beginning, from the user perspective I think this experience was much better than a conventional password system. So now I want to learn how this method is vulnerable and how those vulnerabilities might be mitigated. I understand that this question is less concrete than what is expected for stackoverflow but if not here then where do I get this feedback? Links?
Obviously the actual code may be a security risk but I thought we could get to that level of detail later? If you're interested please try the implementation at the link. The site is themed after a video game so please be patient with the color scheme, only the account control feature is working right now. Navigate to the account page, enter a fake username and a real email address and then if you have multiple devices please try setting access cookies on them. I have verified the program working as intended on 2 Windows/Chrome devices and 1 Android device. None of your information will be retained.
development url
I'm using several social providers on my site, including Google. I would like to ask for password to Google account each time user requests one of my actions. This is for security reasons.
With Facebook, we can send auth_type=reauthenticate parameter. Is there something like this in Google API?
I'm not looking for refreshing tokens, I need to make sure user types his password at any state: whether already authenticated or not.
I read your posts and I can relate to your frustration on this matter (including some of poor responses inline above).
You want to be able to prompt users to reauthenticate with Google in order to prove that the user behind the computer is indeed the account holder. Having required similar functionality myself, I've concluded that they do not implement it. This creates a problem of trust for an application that relies on a Google login for access, but also provides some destructive functionality which should require a reaffirmation of the identity of the user. Wish I had better news for you.
Having implemented this feature with Facebook's API, I was certain Google would provide similar since it's so essential to security, however they don't.
On my site, I intend to offer users the ability to authenticate via OAuth. I don’t want to ask them to first register with me and then connect an external account; I want to offer single sign on.
I believe we’re supposed to reuse Access Tokens; certainly within sessions and even between them.
Google goes so far as to say they’ll limit the number of access tokens to 10 per user per application. (Apparently Google still supports OAuth1, but recommends Auth2 now) 10 is a pretty small number.
Using cookies (like this) seems like a good plan for identifying a user between sessions, but I’m having trouble with the scenario where a user has deleted cookies or connects from a new machine.
How do I know who the user is before I’ve requested another Access Token for them? Request tokens do not contain the userid, right?
Thanks
You will have to maintain your own user accounts anyway, no matter which protocol and which provider you choose. A token (or a URL in the case of OpenID) that you get from a provider is unique for a given user and you are supposed to associate it with your internal user account and recognize user by it.
If you don't want to provide any registration UI it's okay: just get the token, retrieve all the user info you need from the provider and store all this somewhere in your database. You will also have to issue and recognize your own cookie for your users, or else they'll be forced to go through provider auth every time they visit your site.
We are building a PHP multi-tenant application. Each company's account will run on their own subdomain abcorp.example.com. The application allows companies to write and publish content (faqs, etc) for their customers to read.
They will tell their customers to visit: abcorp.example.com/ to read the content. Or they will put a link to that URL in their secure web application.
However these companies may not want just anyone reading the content by going to abcorp.example.com/
So, the question I have is there any way to provide some basic authentication without getting into username and password authentication. I was thinking about some kind of hidden token added to the hyperlink or something like that
My goal:
If users type abcorp.example.com/ directly in the browser, they will not be able to see the web page because they didn't authenticate or pass the token in.
Avoid using username and passwords
Another option would be Referring URL Authentication
Of course, if someone makes the token public, it will open up access to whoever finds it.
I suppose each company could link to their page using a shared token, for example:
abccorp.example.com/?t=4rrfwr23rwads3
Each token could be stored in a file or a database.
When someone requests a page, it checks the value of $_GET['t'] with the one stored on the server. If it matches, it loads the rest of the page. Of course, this variable would have to be carried throughout the site, and included in every link.
Again, this will not be very secure. An exposed token could give access to the site to the entire world.
Your "hidden token" idea is essentialy the way sessions work. A session can be used to identify a user (ie. keep track of what a user does as they browse through the site), and is propagated either by passing the session ID along in links or by storing it in a cookie.
However, using a session without any other sort of authentication is inherently insecure! When you expose the way to authenticate and track users to the user itself, the user can modify or forge their authentication. For instance, the user could change the value passed along for the session ID or change the value stored in the cookie.
Please read the PHP manual section on sessions and security.
Client-side certification. Check out http://en.wikipedia.org/wiki/Mutual_authentication.
You could also use the clients IP address as a token, giving different IP addresses access to different (parts / instances) of the system. But gain, this is not very secure, as
you have no way of knowing who is behind the client PC and
IP addresses can be spoofed. Perhaps you could develop additional specs; giving IP addresses only access during office hours, or check the clients browser (user agent) and check it against the user agent officially being used at the client.
You can use basic hashing whereby a shared secret password or "key" is stored on your system and each company system (a different key for each company and not published publicly), and then you hash the secret password with the subdomain in the link and include the digest as a parameter. Then you validate it by running the same algorithm on your side and compare to the digest.
the link might look something like
abc.example.com/?d=b5939ca22f5dcf345b4000641995478c5910dbd1607b1bdadcbf4a8618a95211
where digest is:
$d = hash('sha256', $secret_password.$subdomain);
or including the referer:
$d = hash('sha256', ($secret_password.$subdomain.$_SERVER['HTTP_REFERER']));
The hurdle to get over is making sure each of the companies can support the correct generation of these links based on the company specific key/algorithm - and that it is different for each company so one company cannot produce links for another.
It is better than no authentication, or a public shared token that is not validated at all, but I'm sure it still has vulnerabilities.
I'm trying to implement single sign-on for a web portal. I've written some code to send a POST request containing the user's login credentials to an external web app to log the user in. (Don't worry, this is all over SSL)
The HTTP response from the web app contains a cookie for the user's login. Is it possible for the web portal server to then pass that cookie to the user's browser? Or is that impossible since the web app is on a different subdomain? I understand there are some security measures built into cookies.
Short answer: NO.
The HTTP server can indeed log into the other service and pass the service's cookie back to the user, but the browser will set that cookie's domain to be the HTTP server's, not the remote service's. There's no way for 'server A' on 'domain A' to make a cookie appear to have originated from 'server B' on 'domain B'. If it were possible, it'd be trivial to steal everyone's authentication cookies for their bank, facebook, myspace, etc...
There are indeed things like cross-domain policies build into modern browsers.
However once upon a time, I created a single login techlology for my own website.
There is a trick you can do. First, on the main site where the users have their
login information, have them a secret generated key. With this unique secret
key to every user, pass them to the other site like
www.abc.com/secret_key
from this secret key, your other website should be able to pull the needed information
like username, profile picture & stuff like that and should create the session on that
domain. So you would have the session created for the opposite domain.
If you still need to pass something back, I would recommend you to go a way that
incorporates RPC over PHP and post something back to your major domain.
This should solve your problems. If you want I can attach some example code.
Note: The security here is in the secret key. Since it's a unique generated key
for example, a md5 hash, it's hard to replicate this. So there is no such thing
like someone could reprocude the secret_key and then login to your site as someone
else.
You should also note that, the secret_key api should only be able to get the
needed information so that not too much information is gathered on the other side.
Why reinvent the wheel? I think that you can find OpenID implementations for PHP. For the consumer and the provider.
You can restrict your OpenID-logins to your domains only if you don't want them to be used elsewhere.