I decided to implement security based on json web tokens, but I have one question. Lets say I have a user Tom and he make a request to my server. As a response he will get jwt token. All subsequent requests from Tom will contain this jwt. Is It possible that somebody will capture his jwt using wireshark or sth else and make a request on behalf of Tom without his knowledge? From a server persperctive jwt will be valid
Yes it is possible. It's called "replay attack". HTTPS makes it much harder to do, but it's still possible even with HTTPS. Related discussion can be found for example here https://stackoverflow.com/a/2770200/43848
Yes it is posible. Anyone with the JWT could impersonate Tom. Use https to avoid an attacker could capture the token from the interchanged messages and keep the token in a secure storage
Related
I am trying to build a registration/login system using the PERN stack (Postgres, Express, React & Node) for a client website.
I was doing some researching and came across HTTP Cookie and JWT token authorizations (many more but apparently those two are the dominant).
I noticed alot apps and tutorials that uses Node JS seems to use JWT alot, and store these in localstorage. But I'm doubtful about the security because I feel like a developer can basically go into localstorage and get the JWT token which o
Is there a better way to secure user authentications with this stack or is using localstorage the rule of thumb? If so, why is that?
Thank you for your time.
One limiting medium to the security of both session IDs and JWTs is network transmission. In this case, both are only as secure as the network itself. But most likely, your application would be using something like HTTPS or SSL, in which case any data being sent across the network would be reasonably secure.
Regarding your other edge case of someone trying to sniff at a JWT in local storage, there are a few options you may consider:
First, the nature of the JWT is that it is generally tamper-proof. A JWT contains inside of it a checksum, which is a unique hash based on the actual contents of the JWT. Let's says that some malicious user sniffed local storage, and then tried to change e.g. the claims section of the JWT. In doing so, this would also change the checksum (which that user would not be able to figure out, lacking the server key). Then, the next time the compromised JWT is sent to the server, the server would reject it, because the computed checksum would not match with the value contained in the JWT.
Second, in the event the above be deemed not secure enough, it is possible to pass around encrypted JWT. If you go with this option, both the server and client would encrypt/decrypt before sending a JWT, which adds an extra layer of protection.
Security of network transmission is just one case of whole solution in web applications.
Im currently in the research of the same topic and as you said a lot of tutorials, blogs, youtube and other sources gives an excellent examples of using JWT tokens for handling user data. Unfortunately hardly anyone go deepest in handling and processing user sessions from administration point of view - where the real problems starts.
Logging the user in and sends JTW token in response to the client is not a problem at all. The problem begin when you as administrator want to invalidate a user.
Refer to this sources:
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
Logout/invalidate a JWT
The session cookie with session data stored in server-side is currently the best option for web application.
i have implemented the tokken based authentication in my project instead of the cookie-session based authentication. So, in jwt(jason-web-tokkens), every time is send req to server,I in headers attach the tokken and send it to server which validate it against the secret is used in generation the tokkkne in the first time and send me the response. Now, i have concern about it, first the tokken is saved in the local storage in browser.although the tokken is hashed but what if the hacker just take that tokken from storage and use it?
can anyone tell me how it stop the CORS attack?
I'm confused and cannot find any reliable answer online.
By CORS I think you are referring to XSS attacks? If so, the best way to prevent XSS is to secure your app against untrusted input. That is easier said than done, here is some information on that:
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
The easier way to prevent XSS is to store the token in a Secure, HTTP only cookie. This means that the Javascript environment cannot touch it, and it will only be sent over secure channels.
Nothing comes for free though :) If you put the token in a cookie, you will also need to setup a CSRF prevention strategy:
https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet
This can be a lot to take in!
I work at Stormpath and I recently wrote this blog post that covers these topics: Token Based Authentication for Single Page Apps (SPAs)
I am implementing a REST API that has both mobile application and browser based clients and users. Based on questions I've asked and previous questions here and at security.stackexchange, I have come to the conclusion that to stay as "RESTful" as I can for as long as I can, HTTP Basic Auth over SSL is sufficient for Authentication. The problem is I'd also like to implement Two Factor Authentication along with it. Is it acceptable to add headers in the 401 Authorization header response, like username:password:token, or in a totally separate request header, but in the same payload as the basic auth response by the client? Since I'm using node.js + express/connect, I have access to the entire HTTP protocol stack, but want to remain as restful as possible for scalability reasons. On the browser side, I guess I could do the basic auth, and if it passes, ask for the TFA token, and only if it passes consider the user authenticated.
You can technically make up new authentication schemes to extend from HTTP Basic Auth, but they generally won't be supported by browsers. In your example, I don't believe any browser would be able to natively ask for and send username:password:token in the same way they can easily ask for username and password.
Generally two-factor authentication schemes work by putting the user into an intermediary state using some form of sessions as you mentioned in your second example. A user who has passed the first factor, say username/password via Basic Auth, has a session opened but not marked as really logged in until they also pass the second factor. Inputting a dongle code or something like that. Once both factors are passed their session is marked as fully logged in and they can access their account/data/whatever.
I'm working on a RESTful(ish) API that has the following authentication style:
A client calls an "authenticate" API method and passes a username and password over HTTPS POST. This method returns basic account information and a "client token", which is stored on the user account in the database.
All further API calls (all over HTTPS POST) require a client token. If the system can't find the requester by client token, the call is rejected.
My open questions are:
1) Does anyone see a major security problem with this?
2) Is there any good reason why I should have client tokens expire over time or change? Right now I assign a random one to every user. If the user does a logout or forgot password, I generate a new one.
I'd love to know everyone's thoughts on this approach. I'm not going for innovation, I'm just making I'm aware of the risks on this approach.
What you've described is functionally equivalent to a session cookie, only reimplemented in your application, and therefore subject to a number of pitfalls that have likely already been dealt with by most web frameworks.
Ensure your tokens have enough bits of entropy. If the tokens are simple 32-bit integers, wild guesses might be enough to hit on one in use by someone else.
If you're generating these tokens randomly, ensure you use a cryptographically-strong source of random numbers, or the next token might be guessable based on previous tokens.
If these POST requests are coming from scripts and such embedded in web pages, passing the token around as an explicit parameter instead of as a cookie declared secure and httponly makes token-stealing by cross-site scripts much easier.
Let's say I have 2 servers (server and authenticator), and I have a client. My end goal here is to be able to identify the client on server. My solution was to come up with a token/secret system like OAuth: client has a token and secret. It passes it to server. Server passes it to authenticator. If valid, server allows the request.
Obviously, this is nonoptimal just for the number of requests being made. The reason authenticator and server are separated is because this is for a decentralised service-- any number of servers may be used, and it's impractical to ask client libraries to register on each server.
So, the question remains, what's the best/correct way to do this? The goal is to create a system that is decentralised, but can still have clients identify themselves in a relatively secure fashion to the server.
Disclaimer: I'm not a security expert so I could be off-base here and in actual implementation there seems to be a number of security issues that would need to be ironed out.
In the broadest sense, could you have the client supply credentials to the authenticator and then upon verification the authenticator supplies the client and the server both with matching security tokens and then the client and server can communicate directly?
Just curious about there a reason you don't want to implement OAuth and run your own OAuth server.
Additional reference: http://groups.google.com/group/37signals-api/msg/aeb0c8bf67a224cc
Turns out the solution was to define my problem a bit better. As I'm only trying to create a way to block applications, I only need to store their name and key when they request the server. Then, as long as they're not blocked and the key matches the one in the datastore, they'll be identified. So I'm not trying to authenticate so much as identify. Thanks for the input!