I'm trying to secure the rest API endpoint with JWT. I looked at a few related questions here and here.
I have some sensitive information in the JWT but I'm using HTTPS, so the data is already encrypted so would that be enough, or do I have to encrypt JWT ?
HTTPS gives you encryption in transport. This means that if anyone intercepts your message they will not be able to read it. But the secure connection is terminated by the browser (at the user side) and very often by a load balancer or API gateway at the server side. This means that the JWT will be freely available to anyone with access to the browser. There is also a possibility that it will be read or stolen from inside your network (once it's past the Gateway/load balancer). This one is a much lower threat, but it nevertheless exists.
If you have sensitive information in the JWT, then there are two options:
You can encrypt JWTs (so use JWEs). This way the token's contents will be secure in the browser. Even if someone reads or intercepts the token there, they will not be able to read it. JWE is a bit tricky to set up, though.
Use the Phantom Token pattern. In this pattern, you issue opaque tokens to the client and have your API Gateway exchange the opaque token for a JWT. This way your sensitive information is kept away from the browser but your APIs can still benefit from the power of the JWT. It also doesn't require setting up encryption. It leaves you vulnerable to any malicious actors inside your network (either from your organization or someone who manages to breach your defenses), but this is a much lower risk.
Related
I'm building an electron desktop app, and in the app it will call the remote API with JWT token. However, where should I persist this JWT token safely without the threats like XSS, CSRF, man in the middle attack etc... and cannot be accessible by other applications
I've tried using node-keytar package, which uses an encryption key derived from the user’s login.
But according to this issue(https://github.com/atom/node-keytar/issues/88), the credential(JWT in our scenario) can still be compromised if the user's environment got a malware installed.
The code of node-keytar is fairly easy, here's the add secret
keytar.addPassword('KeytarTest', 'AccountName', 'secret');
and here's the get secret
const secret = keytar.getPassword('KeytarTest', 'AccountName');
console.log(secret); // "supersecret"
I'm thinking about just storing JWT into the memory might be the safest way, but will require user to re-login and get JWT token everytime they reopen the electron desktop app.
Any suggestions or thoughts are welcomed. Thanks!
In many use cases involving JWT, you would not need to necessarily do any additional encryption/obfuscation of the JWT before you send it to the API, because:
When you send the JWT to the API, you would be doing so via SSL or HTTPS, which encrypts the entire payload. This in theory would eliminate most chances of man-in-the-middle attacks.
Even if someone managed to sniff your JWT token, they would lack the server's key which is required to unlock it. Also, even if they managed to unlock the JWT, it would be almost impossible to alter its contents without also altering the checksum, which is contained within the JWT itself. This eliminates the chance of injection attacks by inserting something into the JWT.
So in general, the JWT pattern is a way of pushing server side session state outside of the application. And it does it in such a way that this state is protected from tampering on the outside. If it were possible to easily tamper with a JWT on the outside, the entire pattern would fall apart.
I understand that the client makes a request to the server, server sends back the token which is used by the clients to make requests. I do not understand how this is secure as the man in the middle can catch the response which comes from the server and use that token.
Maybe I do not understand this fully but I would like to.
Thanks
Your concern of a man in the middle somehow getting a copy of the JWT is a valid one, and, if that were to happen, then the MITM could potentially masquerade as a valid user, using his JWT as identification.
However, this problem only could easily happen if the data being passed between server and client were completely unencrypted. Most likely, your app would be using some form of SSL (e.g. HTTPS) for communication between the server and client. In this case, the most a MITM could obtain would be a bunch of gibberish, which might contain all/part of the JWT. But, he would not easily be able to back out the original JWT.
The main focus of JWT is that they are tamper proof by the client. This means that a user cannot go into his JWT and change his claims or metadata. Rather, the server locks away some claims into the JWT, and only the server can control this. Even a MITM would not be able to tamper with a valid JWT.
I'm trying to implement authentication and session management for a microservice. In order to do the process RESTfully, I understand that I'll need to use some kind of token-based authentication to avoid tracking client session data on the server. The following quote from this answer on the Information Security Stack Exchange nicely sums up my understanding of the implementation:
In Token-based Authentication no session is persisted server-side (stateless). The initial steps are the same. Credentials are exchanged against a token which is then attached to every subsequent request (It can also be stored in a cookie). However for the purpose of decreasing memory usage, easy scale-ability and total flexibility a string with all the necessary information is issued (the token) which is checked after each request made by the client to the server.
From this, I understand how stateless session maintenance is advantageous for scalability, and flexibility as explained. But it seems to me that this leaves the application exposed to some serious problems:
If a hacker somehow intercepts the credential exchange HTTP REST call, they could execute replay attacks on the server get all the information they want.
In fact, since the session token is stored on the client side, couldn't a hacker just retrieve the requisite information from LocalStorage/SessionStorage by debugging the app? Or by monitoring the incoming and outgoing HTTP calls using dev tools? If they get the required token information (even encrypted token information), they could simply start faking REST calls to the server from another window and get all the data they want!
Finally, even if you do give the client a session token, wouldn't the server still have to authenticate that token? In effect, the server would have to maintain session tokens to user mappings...but doesn't that defeat the purpose of a stateless REST-based architecture?
Maybe I am seeing these problems because there is a gap in my understanding. If that's the case, I'd like some clarity of the basic concepts. If not, I'd like to know if there are any techniques to address these specific problems.
I'm building a picture diary on web application google app engine using python. Users can sign up and post pictures to their diary.
Also, I'm trying to conform as much as I can to the REST architecture of doing things.
The authentication scheme is based like this for the web application:
1. Post username/password from the frontend
2. Backend sets up a cookie if authentication is successful
3. The rest of the AJAX calls made are authenticated using this cookie.
Is there any way to conform to REST without using cookies ?
Now, I'm also building an android application where users can sign in and post/view their picture diary. I need to expose the data from web application's datastore so I'll be building a webservice to fetch data from the datastore.
The authentication scheme for the android client:
OPTION a
1. Post username/password over https to the web service
2. Web service returns a unique authorization token (store the token in the username/pwd table on the datastore)
3. Request subsequent services by adding this token to the Request Header of the request
4. Server maps the token to the username/pwd table and returns data if token is found
5. Authorization token expires after a certain period of time
OPTION b
1. Set up a secret key on the client and server side
2. Use "username:hash of password and secret key" in the authorization header of every request
3. server generates the password by extracting the password from the hash value using the same hash algorithm ; if successful returns data
btw, I didn't wanna use basic authorization because of its security vulnerabilities.
Which is better ?
Are there other significantly better ways to accomplish what I'm trying to do ? Security is quite a concern for me btw.
I'd appreciate if anyone has any insight into this issue. thanks.
I've been doing some research myself as to what would be the best solution. I think the 2-legged oauth might work in my case as Leonm suggested.
In this case the server has to provide the client with a consumer key/secret which in my case is hardcoded in the app.
The steps now would be:
1. Generate a signature using the oauth_parameters(consumer_key, signature_method, timestamp), request url, request parameters, and the SECRET.
2. Include the signature, oauth parameters when making a request.
3. Server verifies the request by generating the signature again except in this case it uses the SECRET that corresponds to the key
I think this way I am pretty much confirming to the REST principles. The server is statless as I far I understand now.
What are the pros/cons on doing things this way?
If "security is a concern" then I would say that you'd be a lot better off using open standards and a library to achieve what you want. The main reason for this is that if you do it yourself, you're very likely to forget something; these standards have had a lot of eyes looking at them, looking for holes.
Your options include (in increasing level of complexity)
Basic authentication and HTTPS
Everything is encrypted, which makes it impossible to compress or look into, it increases the overhead somewhat, using more horsepower on the server, and more perhaps battery power on the client. Simple to implement, since it's well supported by libraries.
Digest authentication
Unencrypted messages pass the wire, but the authentication is securely managed in the Authorization headers. See the wikipedia entry for more information.
OAuth
See how Google is providing OAuth for installed applications. I believe it isn't what you're looking for, since you're not asking to share data between applications, just authenticating users.
Roll your own
If you want to roll your own, I suggest looking at e.g. how Google's (now deprecated ?) ClientLogin used to work.
Clients would GET a protected resource, and get a 401 with instructions to perform a GoogleLogin authentication, including a URI for where to perform the login itself
Clients (knowing how to do this) POST a request in a specific manner to that URI
The server responds with a specific response including a (long) token
The client can now perform GET requests to the protected resource with that token.
Statelessness
You cite REST, which dictates that requests should not specifically depend on prior interaction: "... each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server." (fielding) This means that a server shouldn't store conversational context (like an authentication token) in a table.
One way of fixing this is by using any of the token based approaches (where the server tells the client about a token it should use for future requests) where the token is not a random number, but a message to the server itself. To protect yourself from client tampering, it can be signed, and if you're afraid of clients looking at it, you can encrypt it.
Edit: Although I'm not certain, it seems unlikely that Google has a table of all authentication tokens ever issued; The length of their tokens suggests that the token is some encrypted message proving that whoever holds this token actually provided real credentials in some realm at some time.
OAuth does exactly what you want to do in a standard way.
You could use a combination of HTTPS and HTTP Basic Auth. Both are existing standards and should be secure enough when used together.
Background:
I'm designing the authentication scheme for a REST web service. This doesn't "really" need to be secure (it's more of a personal project) but I want to make it as secure as possible as an exercise/learning experience. I don't want to use SSL since I don't want the hassle and, mostly, the expense of setting it up.
These SO questions were especially useful to get me started:
RESTful Authentication
Best Practices for securing a REST API / web service
Examples of the best SOAP/REST/RPC web APIs? And why do you like them? And what’s wrong with them?
I'm thinking of using a simplified version of Amazon S3's authentication (I like OAuth but it seems too complicated for my needs). I'm adding a randomly generated nonce, supplied by the server, to the request, to prevent replay attacks.
To get to the question:
Both S3 and OAuth rely on signing the request URL along with a few selected headers. Neither of them sign the request body for POST or PUT requests. Isn't this vulnerable to a man-in-the-middle attack, which keeps the url and headers and replaces the request body with any data the attacker wants?
It seems like I can guard against this by including a hash of the request body in the string that gets signed. Is this secure?
A previous answer only mentioned SSL in the context of data transfer and didn't actually cover authentication.
You're really asking about securely authenticating REST API clients. Unless you're using TLS client authentication, SSL alone is NOT a viable authentication mechanism for a REST API. SSL without client authc only authenticates the server, which is irrelevant for most REST APIs because you really want to authenticate the client.
If you don't use TLS client authentication, you'll need to use something like a digest-based authentication scheme (like Amazon Web Service's custom scheme) or OAuth 1.0a or even HTTP Basic authentication (but over SSL only).
These schemes authenticate that the request was sent by someone expected. TLS (SSL) (without client authentication) ensures that the data sent over the wire remains untampered. They are separate - but complementary - concerns.
For those interested, I've expanded on an SO question about HTTP Authentication Schemes and how they work.
REST means working with the standards of the web, and the standard for "secure" transfer on the web is SSL. Anything else is going to be kind of funky and require extra deployment effort for clients, which will have to have encryption libraries available.
Once you commit to SSL, there's really nothing fancy required for authentication in principle. You can again go with web standards and use HTTP Basic auth (username and secret token sent along with each request) as it's much simpler than an elaborate signing protocol, and still effective in the context of a secure connection. You just need to be sure the password never goes over plain text; so if the password is ever received over a plain text connection, you might even disable the password and mail the developer. You should also ensure the credentials aren't logged anywhere upon receipt, just as you wouldn't log a regular password.
HTTP Digest is a safer approach as it prevents the secret token being passed along; instead, it's a hash the server can verify on the other end. Though it may be overkill for less sensitive applications if you've taken the precautions mentioned above. After all, the user's password is already transmitted in plain-text when they log in (unless you're doing some fancy JavaScript encryption in the browser), and likewise their cookies on each request.
Note that with APIs, it's better for the client to be passing tokens - randomly generated strings - instead of the password the developer logs into the website with. So the developer should be able to log into your site and generate new tokens that can be used for API verification.
The main reason to use a token is that it can be replaced if it's compromised, whereas if the password is compromised, the owner could log into the developer's account and do anything they want with it. A further advantage of tokens is you can issue multiple tokens to the same developers. Perhaps because they have multiple apps or because they want tokens with different access levels.
(Updated to cover implications of making the connection SSL-only.)
Or you could use the known solution to this problem and use SSL. Self-signed certs are free and its a personal project right?
If you require the hash of the body as one of the parameters in the URL and that URL is signed via a private key, then a man-in-the-middle attack would only be able to replace the body with content that would generate the same hash. Easy to do with MD5 hash values now at least and when SHA-1 is broken, well, you get the picture.
To secure the body from tampering, you would need to require a signature of the body, which a man-in-the-middle attack would be less likely to be able to break since they wouldn't know the private key that generates the signature.
In fact, the original S3 auth does allow for the content to be signed, albeit with a weak MD5 signature. You can simply enforce their optional practice of including a Content-MD5 header in the HMAC (string to be signed).
http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html
Their new v4 authentication scheme is more secure.
http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html
Remember that your suggestions makes it difficult for clients to communicate with the server. They need to understand your innovative solution and encrypt the data accordingly, this model is not so good for public API (unless you are amazon\yahoo\google..).
Anyways, if you must encrypt the body content I would suggest you to check out existing standards and solutions like:
XML encryption (W3C standard)
XML Security