I am storing some basic information to use in order to display information per user. I am currently using cookies to store and retrieve them, however I would like to employ a more secure tactic. I read that using local storage would be more secure and better to use, however, they don't seem to have any expiration date (like cookies) and unless you use a session storage, they will be stored indefinitely, which I don't want. However I don't mind using local storage if the information is encrypted, however with current encryption libraries, I have no idea how to use them.
Storing:
username
login attempts
whether the user is locked out or not
Some things to note: what I am storing is not being used for authentication, only to display error messages. I am using tomcat 8 to handle authentication and running the server (along with lockouts). Even though its not being used for authentication, I don't want to store the username unsecured or without expiration (1-2 days max).
Also, I'm not using an sql database (or other type) but plan to implement later, so don't suggest or ask about it.
I'm looking for the most secure method possible with relative ease, we have other security measures implemented, but don't want to leave any security holes open.
There is no such thing as secure that is purely client-side with two-way encryption. If you are able to decrypt something on the client-side, so can others.
Also, there are no particular security differences between session storage, local storage, and cookies. They're all client-side and able to be read by JavaScript on the same domain.
If you really want things to be secure, you have to store in on the server side, and transfer it only over HTTPS. Anything else is merely security through obfuscation, at best, which isn't real security.
As far as expiration, there is no automatic expiration with either local storage or session storage (other than the session storage will be cleared when the session ends). You could implement some with JavaScript, but that would only involve throwing away values when they are too old, and wouldn't happen until they visited your page.
The best you could do that is almost pure client-side would be to store some kind of key on the server, and when you go to decrypt, it needs to request the key (over HTTPS) from your server and use that to decrypt. That way, they can't decrypt it without having some kind of proper authentication onto your server.
However, if you're doing that, you might as well just store the info on the server in the first place.
Related
My NodeJS application is authenticating users via third-party app. Once the app gets the user data, a cookie is being created and sent to the client and then react is reading user data from that Cookie.
Is cookie better/worse than Web tokens? AFAIK No diff but i want to be sure.
Is there a better implementation?
Can a user modifies req.session info, or that stay in the backend(Node)?
Choosing between cookie and token-based approaches really depends on your use case. When using cookies, session id's are stored in the database. Therefore, with each request back-end will need to perform a database search to check if provided id is present. Using tokens, server only needs to process successful login requests and verify token's validity, which does not require a lot of resources and scales really well. Additionally, with tokens you may use your API outside the browser environment (cookies support is often very limited on other platforms).
If these points are not critical for your application, there is nothing wrong with using cookie-based authentication.
Good luck!
I'm currently working on a mobile app that is built primarily with HTML and css, then run with phonegap. Part of the app requires that the user logs in and sync data with a backend. I want it done in such a way that once the user is logged in on their device they will remain logged in until they manually log out; they should only have to enter their information once. I've found some decent information when working with native code, but not so much that applies to my situation.
Right now, I'm not sure how to properly do this in a way that is secure. My first idea was to handle the login normally, then pass back a secret code that is stored both in local storage on the device, as well as in the database under the user that was authenticated with it. On subsequent requests it would pass this and allow access to the user that had a matching secret code. My question is whether this is secure enough to be practical?
I've also done a bit of research and it appears JWT is similar to what I'm looking for? My two concerns for this approach are:
How do I maintain the persistent login with this method.
What prevents someone from spoofing a connection? From what I know there's a secret string that is passed with each request to verify it. But, since the code in my app would be visible to someone who knew how to access it what is to prevent them from learning what the secret is and spoofing a connection?
I assume my questions with JWT are due to me misunderstanding some fundamentals of how it works. If it satisfies what I'm looking to do I'd much rather use a more standardized process like JWT as opposed to writing my own solution.
Am I on the right track with what I'm thinking above or am I way off base?
Your idea is correct and this is how it's usually done. It is a combination of cookie and session concepts. A 'session' is started on the server once the user logs in. The session is identified by a string (e.g. md5 format) and passed back to the client. The string is saved in a cookie on the client, and since cookie info is sent in each HTTP request, the server can assign that request to the session, thus considering your user as logged in. The signout process later basically consists of removing your cookie, and / or sending a request to the server to remove the session object.
In most HTTP server side frameworks there is an API used for sessions, so you don't have to reinvent the wheel. And yes, it is secure enough, as you don't usually base your security on this layer of transport, but rather on a lower layer by introducing https.
I have an application to which I log in using using javascript. After being authenticated, the server sends me a token, which I have to append to each ajax requests I make to the server so that the server knows that I am eligible to ask for information. However, my application is not single-page application which means that after clicking on links, the page gets reloaded and I need to re-authenticate.
Is it possible to safely save the token and access it again after page reload?
The options I have thought of are saving it in cookie or in local/session storage, however, I'm not sure whether these are safe enough.
Do you know of any other, safer way to save the token on client side? Or perhaps do you know whether the options I mentioned are safe enough to store such a sensitive information?
Thanks for any suggestion.
Edit: I can't change the server-side application, the token must be stored on the client.
Local Storage: is not the safer way to keep confidential/sensitive information.
Cookies: Well there is a lot written about stealing cookies and preventing Cross Site Scripting.
Session Storage: is safe but the question is which technology you are using on the server side.
Is it NodeJS or PHP or anything else??
I have used NodeJS and PHP both for authentication.
With Express.js you can maintain a session for each user and check/authenticate on every request/page load and validate whether it is a valid user/request or not.
And it also provides an active session check i.e, If a user is inactive for sometimes the session will be automatically destroyed/cleared/cleaned.
In addition with passport.js you can also implement this but it depends on your requirements.
Check this LINK
When you think the token is confidential then you should not think about saving it in client side.
Even if you are in a situation where you want to save such a confidential info in client side then the same what you mentioned is correct(Cookie,Local/session storage). Encrypt your token before save.
Local storage:
It is saving data under your domain. No other domain don't have access local storage information of your information.
Please correct me if I am wrong, accept it if I am correct.
Lets rewind to the days of cookies, ok not that far as they are old but still relevant. You can set them and read them with PHP; despite the fact they are a client side technology, you can also use JavaScript, fully client side.
Coming forward in to the future, HTML5 Local Storage, also a Client Side technology can not be set by PHP, you are solely reliant on JavaScript.
It seams as though this is the reverse way of doing it (taking away not adding). Surely to have the ability to set this data with PHP is helpful and possible somehow considering Cookies can be.
So why isn't it possible? What was the reasoning in not designing a way to do this?
Update Correct me if I am wrong, but localStorage is a replacement of Cookies, so does this not mean you are losing functionality?
Lets rewind to the days of cookies...You can set them and read them with PHP; despite the fact they are a client side technology...
No, they aren't. Cookies are primarily a client/server technology. They were specifically designed to allow the server to send information to the client that the client will then send back to the server. From the spec:
This document defines the HTTP Cookie and Set-Cookie header fields.
These header fields can be used by HTTP servers to store state
(called cookies) at HTTP user agents, letting the servers maintain a
stateful session over the mostly stateless HTTP protocol.
Although you can access them via client-side JavaScript, that isn't what they were created for, nor is it their sole purpose.
Web Storage (what you've called "HTML5 Local Storage") is client-side only. If you want to send that information to the server, you do it via ajax or by sending a form.
Why? That takes us into the land of speculation, but we already have cookies, whereas we didn't have a client-only way to store data prior to web storage. A client-only solution is very useful, not least because we can store a large amount of information without it being unnecessarily added to each and every HTTP request that client then makes to your server, which is a waste of bandwidth if the information is only needed client-side.
cookies … can set them and read them with PHP; despite the fact they are a client side technology
They aren't a client side technology. They are an HTTP technology. The are embedded in the communication protocol used between the client and the server.
Local Storage is a purely client side alternative to sessions and databases, which were already available on the server side.
It's purpose is for storing data that is too big for cookies. If you could edit it on the server, then the contents would have to be sent in every request, which would be very expensive. It would also turn Local Storage into "Cookies without the restriction on size".
We've got an app with a json API. We use Javascript in the browser to send ajax calls to it. Each API call requires an API key.
I was planning to implement a login API that would accept a username and password and return the API key for that particular user. The key would go in a cookie and get passed back with every API request. (You would still be able to include it in the json request; the cookie would be a fallback.)
The big benefit of this scheme is that we wouldn't need to maintain sessions on the server side. Everything on the server side would be stateless. There's a significant benefit to stateless operation when you're in a clustered environment.
Is this a bad idea? Is it secure? Is there a better way?
Assume that we're running over https.
Nope, the way you mention, your API keys are not secure this way even though you are using https. That's because the API key now lives on your browser and is susceptible to being exposed either by browser plugins, scripts, etc.
Another thing to consider here is how long are your tokens valid. In such cases it is recommended to have a short API token expiration time.
Fortunately, a lot of people have the same requirement and OAuth 2 spec has a Implicit Grant case flow just for the use case you mentioned. You can look at that and decide your approach,
https://www.rfc-editor.org/rfc/rfc6749#section-4.2
If you don't need support for older browsers, and you only need access to the api key client side, then you can use Local Storage instead, that way you wont have to send a cookie to and from the server, and theres no cookie that can be stolen.