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.
Related
I have variable in Javascript which are created by reading a number from HTML, adding a number to it and then returning it to HTML.
I want to make it so that no matter what browser/what user you are, you are seeing the latest version of the variable. Currently, if I refresh the page then the number resets to 0 (the default value). I want it so that if I update the number to 1 when someone else views it from another browser they will also see 1 and not 0.
I've seen that cookies are an option, however I thought cookies were client side only? So that would mean that only I would see the latest version of the variable.
I've seen that sessions are another option, are sessions server side? And would they do the job that I am after?
Is there another way of doing this I haven't considered?
Thanks in advance
I want to make it so that no matter what browser/what user you are, you are seeing the latest version of the variable.
You need to send your updates from the browser to a server, and then have that server relay your updates to all the other clients. There are many choices for how to do this, with various tradeoffs and complexity.
One method is to simply take that number and send it to the server. Then, on next page load, the server injects that new number into the page it outputs (or it serves it up via an API call, over AJAX, via the Fetch API, or server-sent events, WebSocket, etc.). If you do this though, you will need to decide how to handle concurrency. What will happen if two people load the page at the same time?
The general system you're describing is called Operational Transform, and this is a rabbit hole you probably don't want to go down right now. Just understand that there's no magic that synchronizes things across the planet perfectly and at the same time. Your system has to account for inherent delays in some way.
I've seen that cookies are an option, however I thought cookies were client side only?
Yes, cookies are client-side. They're sent to the server with every request, but that's not a useful tool for you, aside from session identification.
I've seen that sessions are another option, are sessions server side?
They can be, but you need to find a way to know what the user is between browsers. Normally, a session ID is stored in cookies.
I'm trying to make a user log in just once, and have his information on all the servers. Any changes made to the user's information will instantly be available for all servers. Is this possible to do without having each user "log in" separately for each server?
Sort of like the $_SESSION for php, but for Node.js
Design 1 -
What I think would be best to do, but don't know how to share socket data between servers, perhaps using something like PHP's $_SESSION?
Design 2 -
What I'm currently doing:
User uses socket.emit to main.js
main.js adds user information onto the emit
main.js emits to the appropriate server
Appropriate server emits back to main.js
main.js finally emits back to user
This seems awfully inefficient and feels wrong
If your information is primarily static, you can try something similar to JWT. These are cryptographically signed tokens that your authenticating server can provide and the user can carry around. This token may contain information about the user that you want each server to have available without having the user accessing it.
If it's not, you may be looking into sharing a database across all servers, and have that be the point of synchronization between them.
Updates based on our comments (so they can be removed later):
If you decide to use auto-contained JWT tokens, you don't need to be making trips to the database at all. These tokens will contain all the information required, but it will be transparent to the end user that won't have insight into their contents.
Also, once you understand the JWT standard, you don't necessarily have to work with JSON objects, since it is just the serialization approach that you can switch by another one.
You'd provide one of these tokens to your user on authentication (or whenever required), and then you'd require that user to provide that token to the other servers when requesting information or behavior from them. The token will become your synchronization approach.
I have one query on JavaScript.
How we can pass values from one page to another page?
I am working with ASP.NET. My requirement is, I need to validate the user, whether his session expired or not. If the session expired then I need to show a pop up with two textboxes to enter his credentials.
In which case I was unable to do that in ASP.NET. So though of doing with the help of JS. But not getting ideas.
I know we can pass values from one page to another using querystring. But as per the security purpose that is not to be used in my app.
Please help me out.
Thanks in Advance.
Don't do that on the javascript side. Remember that you can't trust the client side.
Use ASP.NET to do this.
See this tutorial to get some help about using sessions: http://www.beansoftware.com/ASP.NET-Tutorials/Managing-Sessions.aspx
You can save the users info in a session, for example his id and current request time. Then you can compare the previous request time, which you saved while processing the previous request, with the current time. You save the current request time in the session again. If it's been to long ago you show him the login popup. If you need a more secure way of passing the login credentials I recommend using a ssl certificate.
You can set cookies. That's also not really secure, but it's obviously a lot more secure than query strings, though if you're dealing with something that requires more security than what cookies offer, then I would suggest that you're doing something really wrong. (Welcome to Stack)
If there is a timeout set on one of our pages, and that same page is opened in another window/tab, is there a way to destroy/stop the timeout in the other window? We have employees who will use our system but open it again from their favorites. If they do this the already opened window will run the interval and then timeout. So while they are working in the new window they opened they will not be able to finish what they are doing because the other window timed them out.
Are there solutions to do this if a new window is opened?
In any sane web application, it is safe to have multiple windows open – especially in respect to session timeouts, because "session" state is managed by the server, not the client.
First, consider why web servers manage session state. HTTP was designed as a stateless protocol, which means any given request cannot conclusively identify who issued the request. This is fine for serving static resources, but is obviously not useful if we want to develop a more interactive app; Netscape later added cookies to their browser to address this.
Cookies solve the state problem (since the browser will issue consequent requests with the cookie[s]), but they are inherently insecure: a malicious client could modify a site's cookies. If, for example, upon login we set a cookie called uid to the user's ID, it would be trivial for someone to fake a cookie with uid=1, which might be your site's administrator account. Oops.
This is why web application frameworks invented the "session" construct. Each time a request is made with no cookie, the server creates a new (random) session key and sets the client's session cookie to that key. The web server keeps track of sessions and all state associated with each session. Important here is that the key itself contains no data, is large and random enough (has relatively high entropy), and is useless outside of your server. It is thus not possible to know how to change the key to gain access to other sessions.
Think of sessions as a large array – one item for each session, and a map of variables in that item. Conceptually, it might look something like this: (remember that this data resides on the server!)
session['safa4fwsa34rff4j9'] = { uid: 1, ... }
session['ajiokinmoi3235000'] = { uid: 4312, ... }
session['9lij34fff032e40k0'] = { uid: 9098, ... }
If I was signed in as user 1, my browser would send a cookie with sid=safa4fwsa34rff4j9. The server looks up this session, and passes the saved state ({uid:1}) on to your scripts. When your scripts are done, the server saves any changes back into its data store. (Session data is often kept in-memory, but in large sites, session data can be saved in a database.)
So what does all of this have to do with timeouts? This session data cannot be kept indefinitely because you'd eventually run out of storage space (whether that means running out of RAM or filling up the database your sessions are stored in).
Instead, the server also stores an expiration date & time with each session. Each time the session is accessed (by a client sending a request with the session's key), the expiration date is reset. The expiration date can be set anywhere from a seconds from now to years from now (depending on what server you're using). You configure how long you want your server to hang on to sessions; IIS defaults to 10 minutes, PHP to ~24 minutes.
In this model, the only thing that really matters is the last time a client issued any request, thus resetting his session's expiration/timeout. It wouldn't matter if multiple windows are open, because as long as one of them have accessed a page recently, all windows will still be active. If the session expires, then all windows are automatically expired when they make their next request.
Something that might muddy this issue is if you're doing some kind of AJAX polling, but the question doesn't indicate what technologies are being used. (#OP, it would be helpful if you included tags for your server stack.)
To summarize all of this: If you're doing any kind session management/expiration on the client, you're doing it wrong. Your app is likely insecure.
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.