I develop a website and I need to store a private key on the client side.
How to securely store this variable on the client side?
Can I use sessionStorage?
(I would like this (variable) information to be accessible only to the current user. As soon as he closes his browser, the data will have to be deleted.)
Thank you.
At a top level, yes, sessionStorage will do what you need. To quote MDN’s page on sessionStorage:
A page session lasts as long as the browser is open, and survives over page reloads and restores.
Opening a page in a new tab or window creates a new session with the value of the top-level browsing context, which differs from how session cookies work.
Opening multiple tabs/windows with the same URL creates sessionStorage for each tab/window.
Closing a tab/window ends the session and clears objects in sessionStorage.
There are several things to be careful of though. Firstly, any connection to the server would need to be done securely. This necessitates an HTTPS connection, probably with TLS 1.2 or 1.3 at this point.
Secondly, you’ll need to make sure that the page environment is clean. This means that you can’t load 3rd party JavaScript that could exfiltrate the private key. At an absolute minimum, any third party JS you load will need to be audited first and then have an integrity attribute added to make sure it doesn’t change.
Finally, you probably would want to add something to destroy the key after the user has finished using the page. This could be warning them to close the page after they’ve finished using the system, or something more automatic like retiring the key after x minutes and getting the system to negotiate a new one in time. Obviously there’s a balance here between security and usability, but the best systems can do this in a user-transparent way.
Related
My web site uses magic links for login, however, I have a problem on mobile (not sure about Android - haven't tried yet, but the problem exists at least on iOS): when a user receives the email say in the GMail app, the link opens in the embedded browser, meaning that cookies will not be passed to the "real" browser.
Is there a way to ensure the link in the email opens in the real system browser and therefore cookies are stored permanently?
(Essentially browser session isolation on iOS breaks a lot of things on the Internet, so surely there is a workaround?)
After some research: no, it is not possible to detect you are in an embedded browser, neither is it possible to enforce opening a link in the system one. Makes sense from security point of view.
However, I was asking the wrong question. The problem of a magic link login is solved differently: when starting a login process you can set a session cookie and create an associated DB record for it, marking it as blocked, i.e. not logged in.
At next step, when the magic link is opened in whatever browser you unblock the session in the DB. At this stage you can replace the login cookie with a real one, e.g. JWT, or continue using it as your main auth token.
If the user then returns to the real browser, you check the login cookie and act accordingly, keeping in mind that it may not be the browser where they validated the magic link. At this stage you can, again, replace the login cookie with your real auth cookie knowing that the session has been validated already.
I'm not entirely sure this is 100% safe, need to think about it more but at first glance it does look safe and seems to be pretty much the only way of handling magic links on mobile.
I'd like to create a web app where the user is able to create a session, with the session being accessible even after leaving the page/browser.
An example would be http://lichess.org where the user goes to 'Create a game' and a page is created. That page then remains accessible even after the session is finished; see: http://en.lichess.org/i8pV0vEv
Essentially what I'd like to know is, what would be needed in order to create a similar effect. I've programmed tonnes over the years, just web environments are new to me! Scala seems like a contender, but in all honesty I have no clue. Perhaps javascript?
Any advice would be appreciated, thanks.
If you want to store user session data permanently irrespective of whether user is on the website or not you may use browser storage facility of HTML 5.
where you can store data on user's browser in form of key value pair and the data will be there permanently(based on type of browser storage you are using) and you can easily manipulate data using javascript.
There are mainly two types of browser storage.
Local Storage: will be there permanently and can be accessed anytime you want.
Session Storage: will be there till the page is open and cleared when user close the browser window.
For your requirement my recommendation is to go for Local Storage
Advantages of Using Local Storage
Can be manipulated easily using JavaScript.
Will be permanent.
No server-side scripting hence, fast to load and manage.
Disadvantages of using local storage
won't work in browser not supporting HTML5(supported in IE 8,chrome 4,Mozilla 3.5,safari 4,opera 11.5 and above)
User will be able to manipulate/delete the value(The browser storage value can be manipulated using resource option of Browser developer tool)
Wont be permanent if user is visiting in In-cognito/in-private mode.(but will be stored during the session.)
Data limit of at least 5MB
Data will be deleted when user clears browser history.
for further reference checkout w3schoold
http://www.w3schools.com/html/html5_webstorage.asp
Web programming is generally session-less and you need a cookie to simulate a session. You save this in your client's browser and in a database to be able to tie them together. Or you can use the browser-session which in the end is also a cookie, but does not scale very well as it's saved in the internal mechanisms of the web-server.
There's nothing Scala specific here, but if you would like to give Scala a try, have a look at Play framework. It's pretty beginner friendly and already has built in support for everything you would need like Sessions, Cookies and Database access.
Our intranet site has an unusual set of requirements.
It functions like a multi-page desktop application. For a single client, our users will be entering information on up to 30 screens.
It is an Asp.Net MVC3 based site with all session state disabled for efficient operation on a web farm.
For privacy reasons, we cannot use the query string to show any client information. We are currently using cookies to store client identification.
Our user base wants to have multiple tabs open in one browser (IE, FF or Chrome).
If I assume that the user is only going to be using a single, then I can store the client info in a simple cookie and everything works fine.
When the user opens a second tab, it would reuse the same cookie. Not the desired condition. So is it possible to determine the difference between the browser tabs?
You can use the sessionStorage object to store data specific to a single window/tab. It works just like any other JavaScript object, in that you can assign (sessionStorage.foo = "bar"), retrieve (baz = sessionStorage.foo) and delete (delete sessionStorage.foo), but unlike other JS objects any properties set will be persistent across pageloads in a single window.
The only downside is that it doesn't send this data to the server. You have to do this yourself using an AJAX call.
Look into the window.name variable. On page load you can put something unique in it, like the date/time, and store the same thing in your cookie (if its not present). If the user opens a new tab (or window), the value will be empty and the cookie won't be. window.name persists across page loads (if memory serves), so this will allow you to uniquely identify each tab.
This is in context to an ASP.Net application. The application makes use of a specific data which is set for a page. After this data has been set all the operations from this page onwards use the set data.
The problem is that if the user opens another tab with a competing data it overwrites the older data for the same session and for the same user which invalidates the operations on the first tab.
I know the suggested way is to refactor the code to remove such coupling but that is not possible. Here's another thread that discussed this but didn't specify any solutions other than refactoring the code (http://stackoverflow.com/questions/632062/ways-to-detect-ctrl-n-or-when-a-user-opens-a-new-window)
So, how can I detect (and notify the user) or stop the user from opening another tab - through javascript/Jquery?
You could set a session variable isActive and set it to true, along with all the other session data when the user opens the application the first time. After this, if the user opens another tab, check to see if isActive is true. If it is, inform the user and don't set the data again.
In pseudo-code, your logic should flow like this
if (!isActive)
//set session data
else
//alert the user: You have another active session
This would be a better solution because there is no guarantee the user does not visit the page to set the session, then temporarily turn off Javascript to launch a new tab without you being notified.
You should realize that you cannot prevent multiple pages being open on the same site by the same user. A user can always do such an operation using multiple different browsers on the same computer or browsers on different computers. As such, what you really need to do is to design your application to either just handle this situation gracefully or detect such a conflict and decide what the safest action is to take when it occurs (chances are, at the server, you either ignore the data from all sessions but one or you somehow merge them all together). What the safe action is depends upon what the data is or how it was changed.
The most straightforward option is to coin a new server-based session for the user each time the user visits and, at the server, invalidate all previous sessions so any older session that tries to make any future updates to the server will be denied because of an invalid session. This prevents any sort of multi-session data conflict.
If you want to be able to inform the user when their session becomes invalid, you could do a slow poll of the server (say once every 20 mins) as long as the window is open and on your site to check the session validity such that you can inform the user when their session has expired.
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.