I am writing an application using Sencha Touch that will require a login to the server. I need a way of keeping track of the session, but I'm not sure what the best way of doing this is. It seems that in HTML5 there is 'sessionStorage' which can be used for this.
From what I understand I need to do the following:
1. Send username/password to server
2. If combo is correct, server sends some session ID variable to phone
3. Phone saves sessionID in sessionStorage
4. Every time the phone communicates with the server it sends sessionID with message
5. Server checks a message for correct sessionID (and possibly checks IP address too)
6. When user logs out of app, sessionID is wiped from phone and server
Can you please let me know if this is the correct route to take?
I usually have handled everything on the client side stored in a JS object. Not sure if it's a best practice or not, but it has worked for me. If I'm storing a password I encrypt it and only match it with the hash to see if it is valid. For session time outs you can set up a timer and for every Ajax request check whether the "session" is still valid.
Related
I am using PHP, AJAX, and JS for my PWA development. I want the user's logged-in state to stay persistent when he/she come back to the PWA app.
Right now I am doing it via the help of the Access token and saving it in the cookie with HttpOnly via PHP. Defining it here -
User enters details, and log in to the app.
That details sent to the PHP backend, via AJAX.
Backend login code check that details from database and if matched, then code create a random hashed token.
Backend code save that hash to the cookie with HttpOnly and secure flag.
User then prompted with a successfully logged-in message.
When the next time the user comes back to the web app, the server PHP code looks for that login hashed value saved in a cookie and finds the relevant user from Database.
If a match found, the user successfully logged-in.
So now my concerns are -
Is this whole process secure and the same as what gets implemented in Industry.
If not, then what can be the best way to achieve this with security.
You can find the answer you are looking for here:)
"Keep Me Logged In" - the best approach
It is important to use an hashed cookie.
On the client side you should use a cookie that represnting the "id" of the "hashed" cookie,
When the next time the user comes back to the web app -> you will check his cookie("id") with the hashed cookie you saved on the server and check for a match(done on server side).
Note: the hashed function is done on your server.
One more thing: never let that cookie(hashed) leaves the server.
Where should I store a client secret in a JavaScript application to prevent other users from getting access to it? My particular use case is an AngularJS SPA.
The client secret is a guid which is generated at login and passed back to the client, expires after 15 minutes of inactivity.
Considering the nature of my secret key, should I even care?
2 things:
One: You can't. It's on their side, anyone with access (to the computer while that user is logged in) and knowledge will be able to see it. As well as anyone that intercepts the transmission from client to server (if your not using https).
Two: It's not necessary if you are implementing it correctly.
Meaning will it ever be valid again, after it expires, or is it a one off*?
Is it authenticated against the other half on your server?
*By one off, I mean a GUID is supposed to be globally unique. Are you using the same GUID each time for each user or are you scrapping it and the next time assigning them a new one? If the first you have an issue.
If your doing all those things then you really don't need to worry about it.
I want to learn what is the best practice to check login status at client side. What I am trying to do is checking user's login status and if he is not logged in open popup box (login box) using JavaScript.
I can think of 2 options
Make an AJAX call to server and get the login status.
Have a variable in your HTML page and check this variable with
JavaScript at client side. Of course I do not trust this check, I
still have all the necessary checks in my controllers at server
side.
Option 1 is good but it can add some latency/delay so it may not be the best option in terms of user experience. Or am I wrong, with a good server (I am planning to use amazon web services) this delay will be so minimum and user will not understand it (Question may look silly but this is my first web development so please be understandable :))
I can't see any problem with option 2, please correct me if I am wrong. As I said I am trying to understand the best practice.
The best way to avoid server hit/network latency as well; You can put a client variable which has the login status (as you said in your question), but main thing to avoid server hit and network latency (AJAX), You just use the same logic which is at server side to set the login status as false. Suppose say the logic is to sety login status to false after 5 minutes of inactivity, You can do the same at client side as well.
So overall I mean to say is, Implement the same logic at client end to set the login status false. and based on that you can show your login dialog immediately with any latency. And in BEST PRACTICE you should always do double verification i.e. at server end on each and every requests for authenticated stuffs you should check that the client login status matches the server login status, since the client's login status can be tampered one.
Good Luck... Happy exploring :-)
Option 1 seems the best, how can you otherwise know if the cookie you save the user id in was not tempered with?
As far as I know the best practice is to add a hash to the cookie (you can see google doing that in their cookies), and then use that to check if the data in the cookie is valid on the server side, using a secret and or salt.
http://en.wikipedia.org/wiki/Hash_function
http://en.wikipedia.org/wiki/Salt_(cryptography)
what you could do anyway though is check if a cookie exists with userid in your client side javascript, and if not, then send the user to the login page.
https://developer.mozilla.org/en-US/docs/DOM/document.cookie
that way you don't need a server round trip for obviously logged out users.
However, can't you on the first request the user makes to your serveralready do the checking? and if the user is not logged-in respond with the login page?
I need to access an api which requires http authentification on a per user basis using a jquery mobile api.
I plan to make the app available as a website as well as packaging it in Cordova for various devices.
If I have a login form which captures the username and password and store this as a javascript variable, is there any way this data could be exposed?
If so, what's the best alternative to handle storing the users authentification details? I am reticent to build an intermediary server if I don't have to.
Many Thanks. :D
I would suggest not storing the username or password in the localStorage, but instead to store an access token. Access tokens can be updated and changed frequently, it also doesn't reveal who the user is or what their hashed password is.
Besides iOS Keychain or if you're coding it for a non-iPhone device for added security you can:
Change the access token at each login and each time the app is used
Store the device ID in the server database (see http://docs.phonegap.com/en/2.2.0/cordova_device_device.md.html#device.uuid)
Clear the localStorage and request a new login if the access token or device ID doesn't match the data stored in the database
Make sure you don't store the device ID in the localStorage.
For added security you can also store the user's IP address in the database and check (server side) if the IP address matches, but this might too much since the user would have to login every time they connect to the internet in a new location or if their IP address changes.
Storing the IP address in the server database then checking if it matches (server side) would probably be the safest since it wouldn't matter if someone got hold of the localStorage data.
So I understand you don't control the backend you log in to? If you do, I would be more inclined to send username/password once, and then store some access token that will allow you subsequent access.
If you don't control the backend, you're stuck with storing username/password. I would say, setting them in localStorage is as safe as it gets (which is, admittedly, not very safe. Then again, if your login doesn't happen on HTTPS, I would be more worried about passwords leaking there than from the device itself). You could make the passwords harder to find, not call the variables "username/password", encrypt them in javascript, obfuscate your code. But in the end, they can always be retrieved without too much effort with the right access to the device.
After packaging as native app, you have more options, e.g. iOS keychain: http://shazronatadobe.wordpress.com/2010/11/06/ios-keychain-plugin-for-phonegap/
I just want to know which one is the best way to handle the cookies?
Using Express.js? Node.js or client side javascript jquery?
I am little confuse with security perspective.
Thanks for all your help/information.
Cookies are HTTP concepts which is irrespective of the language / platform. So, Node.js is a server side platform while Express.js is a server side web application framework for Node.js and jQuery is a client side library.
From security perspective, you should not store cookie information in plain text. Also, "you shouldn't allow client side scripts to set or read the cookie value". If you are already using Express.js, then I would recommend setting & reading of cookies to be taken care by your application using Express.js and ensure you encrypt the cookie values.
You should keep some session id in cookie, not actual data (it's true for most cases, especially for any user-related sensitive data).
The correct approach for using cookies would be:
Make user input his login/password and check "keep logged in" checkbox.
On server side, based on inputed login and password, decide if user credentials are valid.
Assuming valid credentials, create some random id and store information on server side, that this given random id is related to some data (some user id, settings etc.).
On server side, based on value of "keep me logged in" checkbox you would then do following: if checkbox was checked, create cookie that should expire in some time in very distant future (like, say, 100 years). If checkbox wasn't checked, you set cookie to expire once browser session is over or for example in 1 hour. Keep in mind, that user can tampre with expiration date of cookies once you send them, but that's a whole different story.
User (client) is receiving your cookie which has that generated id in it. That cookie is sent to you by browser on every request.
On server side, once you get your cookie from client, check if you know that id and if it is valid. If so - retreive user data from your databse or whatver and operate on those.