I've been building an app (ios and web app) on Parse over the last few months and have only just discovered how their session tokens work. This is what I have learnt so far:
Each user has their own session token
The token is used to replace the user credentials (for authentication) when making requests to the server
The token never changes (even when password is reset) and never expires
The token is stored locally on client side when logged in
User can be logged in using the Parse.User.become(sessiontoken, options) method, with only the session token
This seems very insecure to me, or am I missing something? It seems that if anyone manages to get this token they have eternal access to the users account, even if username and/or password are changed?
Thanks,
Mario
Looks like they have just updated their systems to use revocable user sessions. Nice one Parse!
http://blog.parse.com/2015/03/25/announcing-new-enhanced-sessions
I have also double checked the session token returned from REST API & Android Client. It is the same. Even after I changed the password.
This is definitely a potential security issues. Anyone who's mobile device is stolen, the hacker could get the session token if the session is not encrypted and the security of user data is in jeopardy forever.
As the hacker could use the session token from any client forever. You will never know when the hacker will do the evil.
I am seriously concerned about the issue. Hope somebody will address it.
PS: Hi Mario, I have logged an issue on the Facebook Developer Platform.
https://developers.facebook.com/bugs/309490399239393/
Hope somebody will track it and resolve it eventually.
Related
I have stuck in here and couldn't find a solid solution.
I use PHP in server-side and Vanilla JS in the client side.
In server-side, I'm generating a auth token (https://www.pubnub.com/docs/general/basics/manage-access) for current logged in user's channel to make him able to read his channel messsages by the following code:
I'm also generating a new one when the key timeout so all OK with the generation.
But my problem is starts here:
I'm passing the key into the client like this:
And user is getting access to the channel. But the thing is, I'm passing this auth key to the client-side. Which is someone that get this user's auth token; can setup their own client and can read messages that sent to this user.
How can I deal with that?
And another one:
I'm publishing to a channel in PHP like this. But I'm able do to that without setting auth token. I'm sure auth token system is working because when I pass wrong auth key to the client it's giving 403 forbidden. But however, I'm able to publish to channel without auth key in here. Is this because it's server-side?
Thanks!
Googled everything...
someone that get this user's auth token; can setup their own client and can read messages that sent to this user
This authorization strategy is the same as JWT. How will someone get this auth token? If you are using a secure connection to your server (TSL, aka https), and your PHP server is secured, then that is all you can do. This is the internet :)
Now how secure is the end user's machine? Are they susceptible to phishing or other schemes that might allow a hacker to gain access to their machine? Humans are the easiest thing to hack and you can't really do anything to secure them ;)
So as far as PubNub is concerned with security, you are doing exactly what very large companies have been doing for over 10 years with PubNub. The question is how secure is your server that a hacker can't get access to your code and data and get your PubNub secret key. In my 9+ years at PubNub, I've never known this to happen.
granting permissions on your channel
You are granting too many permissions but it doesn't have any negative side effects.
read - subscribe (receive messages), fetch (messages from history), and some presence stuff (get/set state, here now)
write - publish (send messages)
get and set - this is for PubNub Objects only which is different than pub/sub.
Again, no harm comes from granting permissions that have no effect on the resources you are granting to but it adds to the size of the auth token (just a little bit in this case).
able do to that without setting auth token
When you do setToken you are setting that on the pubnub object that you use to invoke PubNub operations. The PubNUb SDK automatically adds the auth token as a query parameter in the request. So it is being passed automatically for you.
Open your browser console, select the Network tab, and look at any PubNub request/url. You will see the query parameter names auth and the value is your auth token.
PubNub Secret Key give you all access
The secret key gives your server the ability to grant permissions (generate an auth token) AND it gives your server all access to all things in your PubNub key set. Don't let that secret key get compromised.
I am using Laravel as my backend together with Sanctum which generates personal access token for mobile users. For my mobile application I am using flutter.
To authenticate users they login with their username/password and get a personal access token in return. This works but requires a user to login every time they open the application again so I did what most tutorials suggest which is saving the token on the mobile device using shared preferences/secure storage.
Now comes the question how do you invalidate a user when you remove their token from the backend? On initial login it appears everything is still fine because like in most tutorial I check for the existence of a token. After that whenever I want to make a request which uses the token I obviously run into problems because it not longer exists on the backend.
Most tutorials/guide suggest saving the token and using that a reference to see if the user is logged in or not but this seems flawed because it gives the false impression you actually have a valid token.
My guess is this can be solved by always performing a heartbeat/ping action to check if the current token is valid and if not send them to the login screen instead of simply checking for the existence of the token.
Thoughts on this?
I can suggest a hack or trick here in every launch of the app you can send a request to an API to check if the user's token is valid or not and if it is valid then you can continue the app otherwise force the user to login and generate new token this way your app will be secure via server / API.
For this, you can store the user's secret token in the database and check it via HTTP API call and send a response from the API accordingly and check the response in app and do the next operation according to the response you get.
I don't know if this is a great way of doing this job but it is a kind of hack/trick to achieve what is needed.
Thanks
I am quite confused which is more safe Authentication Token vs Cookies - Session Authentication
While searching on the net I found Authentication Token is more fast & secure to use.
But what I conclude that Cookies - Session Authentication is more safer because Session is create on the server which is secure and no client side user get access to it.
while Authentication Token is simply work on the hash string, stores on client side. Anybody can access the string and copy the string and make the further request from other system If the token is not expired.
Is Access token really work If I copy the string from one system and run on other system.
I am so confused, Can anybody correct me here.
I don't think you have read carefully. Note that cookies are saved in client's side (eg. browser). So, if someone put a little effort and manipulate the cookie, he/she can easily use that cookie info to access the server or what ever; you get the point.
I've just realized that if I log out from facebook.com, the access token in my app is no longer valid (fbSessionInvalidated gets called).
I don't understand why logging out from the Facebook website would invalidate the access token in my app. Is this normal behaviour, and if so why is it happening?
it's normal, you need to ask a offline token.
But be carefull Since 2nd of may.
This is in place http://developers.facebook.com/roadmap/offline-access-removal/
I just enabled "Remove offline_access permission" in my app's advanced settings and this problem is fixed (I also get 60 days access tokens now).
i'm reading an old applicaiton which saved the users usernamea nd password as a cookie - as a "rememeber me" feature. What's wrong with this approach, if anything?
i guess the password can be ferretted out if someone does a malicious javascript injection on one of the pages of the site, but any other security risk besides that?
You're transmitting the password, in the clear, over the Internet with every HTTP request. If you're not using SSL, there's a risk of eavesdropping.
An obvious one is if somebody intercepts the cookie when it's sent from the user's browser to your server, they can then impersonate that user. See Firesheep.
The cookie is in the client, so anyone with access to the user's computer can read it.