I'm developing a MEAN stack application, and I'm currently setting up an account system. I've seen several tutorials about Authentication, all using JWT.
I am wondering if, JWT could be used as way to secure communication transport over non-secured connection like HTTP?
I've set up HTTPS to communicate from my Angular 4 front-end to my NodeJS + Express back-end, and thus, wondering if JWT are necessary to secure my communications?
JWT should not be confused with encryption. From jwt.io:
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a
compact and self-contained way for securely transmitting information
between parties as a JSON object.
The JWT is signed with public/private key pairs so the sender can be verified, and verified that the payload has not been modified. However, the JSON Web Token is in clear text.
var token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ";
var payload = token.split('.')[1];
console.log('Payload: '+atob(payload))
Below is a figure from jwt.io showing the authentication flow when using JWT.
You need SSL/HTTPS to encrypt the communication. Without SSL/HTTPS attackers can sniff the network traffic and obtain the JWT, hence your application is vulnerable to man in the middle attacks.
Is JWT necessary over HTTPS communication?
No. Communication protocol (HTTP v.s. HTTPS) is one thing, and authentication mechanism (JWT v.s. Session) is another -- these are 2 totally different area.
For communication protocol (HTTP v.s. HTTPS), HTTPS can be used alone, without any JWT tokens or sessions. For example, a static web site can be made (only HTML+CSS) and served with HTTPS. In this way, the web site can be certificated by CA and prevent forge attack.
Even if you need authentication in web application, JWT token is not the only choice. Session is old technology but it is still reliable, which made JWT definitely NOT necessary.
No, JWT is not required when your server supports HTTPS.
HTTPS protocol ensures that the request & response are encrypted on the both(client & server) the ends.
I believe you would want to send across user credentials in every request to the server, and in turn server validates the user before sending any response from the server.
Although you can do the above, but on the server-end, you would end up validating user credentials against a Database in every request which is a expensive task, you can avoid this when you use JWT.
JWT basically authenticates a user once & issues an access token which could be valid for a duration of time.
Nowadays developers prefer Token-Based Authentication instead of Session. Token-Based Authentication has lots of advantages over Session.
We use JWT i.e. JSON Web Token to generate a token after user authentication, every time your front-end app makes an API call so your system should check whether the request has a valid token or not if it is there and it is valid then it is considered as the valid user.
In short, we use JWT to validate our API calls it is nothing to do with HTTP or HTTPS
I'm new to JWT. Here is my scenario of an attack of JWT when it's in the http instead of https. Suppose a JWTa is issued to userA for accessing resource A on the server. A hacker is also a legal user of the server, he got JWTh to access resource H. Without the https protection, the hacker can sniffer the network and get the JWTa in the http header from A's request and put it into the hacker's request. Since JWTa is a valid token, so the hacker can access resource A. I guess the JWT protocol can prevent this, but I don't know how. After the signature is verified, the claim also needs to be verified. Seems the "aud" can prevent this, but I don't know how it works exactly.
Related
I'm going to implement my authentication method using JWTs in node js.
I was searching a while for different methods of authentication and finally decide to use JWTs.
However I am confused about the JWT based authentication.
Here's my question : Should we send our JWT over HTTPS? if yes, then why should we use JWT at all ? and why not sending all needed information over HTTPS without JWT ?
In other words when there is security issues without HTTPS (like man-in-the-middle attack), what is the reason of using JWT for authentication purposes? is there any other authentication approach which works perfectly without using HTTPS?
Here you are mixing two different protocol levels.
HTTPS (or rather TLS - transport level security) is a transport layer - data transport pipe ensuring you communicate with a legitimate server and that nobody could read or change the data exchanged. HTTPS doesn't care about data itself (e. g. authentication)
JWT is commonly used as part of the payload (data itself) describing client's identity and other attributes.
Most commonly you need both - JWT to ensure authentication or authorization and TLS/HTTPS to ensure that nobody could steal or change your JWT token or data.
HTTPS could provide client authentication, but the client needs to have its client keypair and certificate which is not really free or easy to manage (e. g. this is how electronic ID cards work or I see it often in the server-to-server scenarios).
To expand on #gusto2
JWT and HTTPS accomplish different goals. Three major components of security systems.
C - Confidentiality - Is data secure from outsiders reading it?
I - Integrity - Is data secure from outsiders tampering with it?
A - Authenticity - Is data sent from the proper person
HTTPS ensures confidentiality and integrity.
JWT helps with authenticity. However, it is your job to ensure that tokens
are valid. This is not provided out of the box.
“and why not sending all needed information over HTTPS without JWT ?”
I think the main point is that Restful or API based interaction is stateless. So in all interaction server needs to get the token to know the authenticity. And for authenticity that all requests are coming from logged in authentic user it needs to get same JWT.
Hence answer to the question in OP as Daniel said is for Authenticity.
In normal form based request we do not use token, why? Because it is stateful and we save information in session or cookies. But APIs are stateless so some token needs to be sent.
I've read through a lot of long explanations of CSRF and IIUC the core thing that enables the attack is cookie based identification of server sessions.
So in other words if the browser (And note I'm specifically narrowing the scope to web browsers here) does not use a cookie based session key to identify the session on the server, then a CSRF attack cannot happen. Did I understand this correctly?
So for example suppose someone creates a link like:
href="http://notsosecurebank.com/transfer.do?acct=AttackerA&amount;=$100">Read more!
You are tricked into clicking on this link while logged into http://notsosecurebank.com, however http://notsosecurebank.com does not use cookies to track your login session, and therefore the link does not do any harm since the request cannot be authenticated and just gets thrown in the garbage?
Assumptions
The OpenID Connect Server / OAuth Authorization server has been implemented correctly and will not send authentication redirects to any URL that you ask it to.
The attacker does not know the client id and client secret
Footnotes
The scenario I'm targeting in this question is the CSRF scenario most commonly talked about. There are other scenarios that fit the CSRF tag. These scenarios are highly unlikely, yet good to be aware of, and prepared for. One of them has the following components:
1) The attacker is able to direct you to a bad client
2) The attacker owns that client
3) The attacker has the secret for that client registered with the OAuth Authorization Server
4) The attacker is able to tell the Authorization Server that authenticates you to redirect back to the bad client after you have been authenticated with the proper server.
So setting this up is a little bit like breaking into Fort Knox, but certainly good to be aware of. For example OpenID Connect or OAuth Authorization Providers should most likely flag clients that register redirect URLs pointing to redirect URLs that other clients have also registered.
The most common / usually discussed CSRF Cross Site Request Forgery scenario can only happen when the browser stores credentials (as a cookie or as basic authentication credentials).
OAuth2 implementations (client and authorization server) must be careful about CSRF attacks. CSRF attacks can happens on the client's redirection URI and on the authorization server. According to the specification (RFC 6749):
A CSRF attack against the client's redirection URI allows an attacker
to inject its own authorization code or access token, which can
result in the client using an access token associated with the
attacker's protected resources rather than the victim's (e.g., save
the victim's bank account information to a protected resource
controlled by the attacker).
The client MUST implement CSRF protection for its redirection URI.
This is typically accomplished by requiring any request sent to the
redirection URI endpoint to include a value that binds the request to
the user-agent's authenticated state (e.g., a hash of the session
cookie used to authenticate the user-agent). The client SHOULD
utilize the "state" request parameter to deliver this value to the
authorization server when making an authorization request.
[...]
A CSRF attack against the authorization server's authorization
endpoint can result in an attacker obtaining end-user authorization
for a malicious client without involving or alerting the end-user.
The authorization server MUST implement CSRF protection for its
authorization endpoint and ensure that a malicious client cannot
obtain authorization without the awareness and explicit consent of
the resource owner
Theory is, CSRF is not related to the authentication method. If an adversary can have a victim user perform actions in another application that the victim didn't want, then that application is vulnerable to CSRF.
This can manifest in several ways, the most common being that a victim user visits a malicious website which in turn makes requests from the victim's browser to another application, thus performing actions the user didn't want. This way it is possible if credentials are sent by the victim browser automatically. By far the most common scenario is a session cookie, but there can be others as well, for example HTTP Basic auth (the browser remembers that as well), or Windows authentication in a domain (Kerberos/SPNEGO), or client certificates, or even some kind of an SSO under certain circumstances.
Also sometimes application authentication is cookie-based, and all non-GET (POST, PUT, etc.) requests are protected against CSRF, but GETs are not for obvious reasons. In languages like PHP, it is easy to make calls intended to be POST requests also work as GETs (think of using $_REQUEST in PHP). In that case, any other website can include something like <img src='http://victim.com/performstuff¶m=123> to have actions performed silently.
There are also less obvious CSRF attacks in complex systems or flows, like for example the CSRF attacks against oauth.
So if a web application uses say tokens (sent as request headers, instead of session cookies) for authentication, meaning a client will have to add the token to each request, that is probably not vulnerable to CSRF, but as always, the devil is in the details.
I want to know a technique with which server can identify if data coming in the request is not modified by an attacker. We are having REST APIs on server side which will be invoked from a mobile app client or a browser. I was thinking of using JWT (JSON Web Tokens). But not sure how it will achieve this. People have used JWT for session management purpose mostly. I do not need the session management. I just want to detect the request data modification. need some help here...
It depends on what type of attacker you wangt to protect against, but the TL;DR is you don't have to do anything as any such protection is either unnecessary (with some special case exceptions as detailed below) or useless.
Protecting against a valid user modifying his own requests
There is no point in this. Any secret you would use for such protection (for signing requests, essentially) would have to be sent to the client so that it can use it to sign whatever it wants to. But if it is sent to the client, the user already has it and can use it to sign any modified request. You have to architect the application in a way that security is enforced on the server side and valid users can't forge requests that they are not supposed to make.
Protecting against a man-in-the-middle attacker
Let's suppose you want to protect requests against somebody between the user and the server. If you access the server over a secure channel (https), it already does this for you, you don't have to implement anything in addition to that.
However, I can think of special cases. First, you may be worried about intermediate proxies that terminate SSL, like for example a company proxy that serves https websites with its own certificate, set as a trusted root on company clients. This is fairly common practice, but usually you as the application developer don't want to deal with this. The other thing is when you don't want to use SSL, but I'd say it's rather a special case when you are worried about request integrity, but not about confidentiality.
Anyway, if you are in a situation where you do in fact need to maintain integrity in another way besides (or instead of) https, you could give your client a secret and sign requests with that secret, like for example using HMAC or another message authentication protocol. You would take relevant fields from request headers and also the whole request body, create an HMAC of them with the secret and attach that to the request. The server, having the same secret for the client could create the same hash and verify if the client had the secret and also that the request sent is the same as signed by the user. Note that to prevent replay attacks, you would also have to include a timestamp and/or a nonce header in the signature.
The question then is how you get this secret to the client securely, and depending on your circumstances, this can be a tricky one to solve.
Edit
I just realized you had csrf as a tag to the question. Be aware that csrf has nothing to do with modified requests, and you do have to implement protection against csrf in general.
The JSON Web Signature is a cryptographic mechanism designed to secure data with a digital signature unique to the contents of the token in such a way that we are able to determine whether the data of the token has been tampered with or not.
source: php-authorization-jwt-json-web-tokens
You can use JWT to verify client requests but the client need to request a token (at least once) before any verifiable request.
Tokens are created on server side only using a secret key (never sent to the client) used to encode/sign the token, the client can decode and access the token but doesn't modify it, just send it back as it is.
I have a private rest API. Each of our clients websites currently performs server side authentication over SSL to start an order with us. Each client has a unique client id so I can identify which client is making the request and reject any client id which doesn't exist in our system. Is there a way to do this securely from the front end of a clients website with javascript? I can't put the client id in the client code since any developer could look at the source code and figure out how to spoof requests from another site. I think checking referrer headers is not reliable as well? Would really like to know the best practice for situations like this.
Not sure if I understand your question correctly, but typically you would encode your client id as a claim in the security token issued when authenticating your users. As the security token is signed by the issuer, you can verify that the token is not modified when you receive the token on each request.
Obviously you will need to use the https protocol to prevent the token from being stolen. See here for more information.
When building SPA style applications using frameworks like Angular, Ember, React, etc. what do people believe to be some best practices for authentication and session management? I can think of a couple of ways of considering approaching the problem.
Treat it no differently than authentication with a regular web application assuming the API and and UI have the same origin domain.
This would likely involve having a session cookie, server side session storage and probably some session API endpoint that the authenticated web UI can hit to get current user information to help with personalization or possibly even determining roles/abilities on the client side. The server would still enforce rules protecting access to data of course, the UI would just use this information to customize the experience.
Treat it like any third-party client using a public API and authenticate with some sort of token system similar to OAuth. This token mechanism would used by the client UI to authenticate each and every request made to the server API.
I'm not really much of an expert here but #1 seems to be completely sufficient for the vast majority of cases, but I'd really like to hear some more experienced opinions.
This question has been addressed, in a slightly different form, at length, here:
RESTful Authentication
But this addresses it from the server-side. Let's look at this from the client-side. Before we do that, though, there's an important prelude:
Javascript Crypto is Hopeless
Matasano's article on this is famous, but the lessons contained therein are pretty important:
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
To summarize:
A man-in-the-middle attack can trivially replace your crypto code with <script> function hash_algorithm(password){ lol_nope_send_it_to_me_instead(password); }</script>
A man-in-the-middle attack is trivial against a page that serves any resource over a non-SSL connection.
Once you have SSL, you're using real crypto anyways.
And to add a corollary of my own:
A successful XSS attack can result in an attacker executing code on your client's browser, even if you're using SSL - so even if you've got every hatch battened down, your browser crypto can still fail if your attacker finds a way to execute any javascript code on someone else's browser.
This renders a lot of RESTful authentication schemes impossible or silly if you're intending to use a JavaScript client. Let's look!
HTTP Basic Auth
First and foremost, HTTP Basic Auth. The simplest of schemes: simply pass a name and password with every request.
This, of course, absolutely requires SSL, because you're passing a Base64 (reversibly) encoded name and password with every request. Anybody listening on the line could extract username and password trivially. Most of the "Basic Auth is insecure" arguments come from a place of "Basic Auth over HTTP" which is an awful idea.
The browser provides baked-in HTTP Basic Auth support, but it is ugly as sin and you probably shouldn't use it for your app. The alternative, though, is to stash username and password in JavaScript.
This is the most RESTful solution. The server requires no knowledge of state whatsoever and authenticates every individual interaction with the user. Some REST enthusiasts (mostly strawmen) insist that maintaining any sort of state is heresy and will froth at the mouth if you think of any other authentication method. There are theoretical benefits to this sort of standards-compliance - it's supported by Apache out of the box - you could store your objects as files in folders protected by .htaccess files if your heart desired!
The problem? You are caching on the client-side a username and password. This gives evil.ru a better crack at it - even the most basic of XSS vulnerabilities could result in the client beaming his username and password to an evil server. You could try to alleviate this risk by hashing and salting the password, but remember: JavaScript Crypto is Hopeless. You could alleviate this risk by leaving it up to the Browser's Basic Auth support, but.. ugly as sin, as mentioned earlier.
HTTP Digest Auth
Is Digest authentication possible with jQuery?
A more "secure" auth, this is a request/response hash challenge. Except JavaScript Crypto is Hopeless, so it only works over SSL and you still have to cache the username and password on the client side, making it more complicated than HTTP Basic Auth but no more secure.
Query Authentication with Additional Signature Parameters.
Another more "secure" auth, where you encrypt your parameters with nonce and timing data (to protect against repeat and timing attacks) and send the. One of the best examples of this is the OAuth 1.0 protocol, which is, as far as I know, a pretty stonking way to implement authentication on a REST server.
https://www.rfc-editor.org/rfc/rfc5849
Oh, but there aren't any OAuth 1.0 clients for JavaScript. Why?
JavaScript Crypto is Hopeless, remember. JavaScript can't participate in OAuth 1.0 without SSL, and you still have to store the client's username and password locally - which puts this in the same category as Digest Auth - it's more complicated than HTTP Basic Auth but it's no more secure.
Token
The user sends a username and password, and in exchange gets a token that can be used to authenticate requests.
This is marginally more secure than HTTP Basic Auth, because as soon as the username/password transaction is complete you can discard the sensitive data. It's also less RESTful, as tokens constitute "state" and make the server implementation more complicated.
SSL Still
The rub though, is that you still have to send that initial username and password to get a token. Sensitive information still touches your compromisable JavaScript.
To protect your user's credentials, you still need to keep attackers out of your JavaScript, and you still need to send a username and password over the wire. SSL Required.
Token Expiry
It's common to enforce token policies like "hey, when this token has been around too long, discard it and make the user authenticate again." or "I'm pretty sure that the only IP address allowed to use this token is XXX.XXX.XXX.XXX". Many of these policies are pretty good ideas.
Firesheeping
However, using a token Without SSL is still vulnerable to an attack called 'sidejacking': http://codebutler.github.io/firesheep/
The attacker doesn't get your user's credentials, but they can still pretend to be your user, which can be pretty bad.
tl;dr: Sending unencrypted tokens over the wire means that attackers can easily nab those tokens and pretend to be your user. FireSheep is a program that makes this very easy.
A Separate, More Secure Zone
The larger the application that you're running, the harder it is to absolutely ensure that they won't be able to inject some code that changes how you process sensitive data. Do you absolutely trust your CDN? Your advertisers? Your own code base?
Common for credit card details and less common for username and password - some implementers keep 'sensitive data entry' on a separate page from the rest of their application, a page that can be tightly controlled and locked down as best as possible, preferably one that is difficult to phish users with.
Cookie (just means Token)
It is possible (and common) to put the authentication token in a cookie. This doesn't change any of the properties of auth with the token, it's more of a convenience thing. All of the previous arguments still apply.
Session (still just means Token)
Session Auth is just Token authentication, but with a few differences that make it seem like a slightly different thing:
Users start with an unauthenticated token.
The backend maintains a 'state' object that is tied to a user's token.
The token is provided in a cookie.
The application environment abstracts the details away from you.
Aside from that, though, it's no different from Token Auth, really.
This wanders even further from a RESTful implementation - with state objects you're going further and further down the path of plain ol' RPC on a stateful server.
OAuth 2.0
OAuth 2.0 looks at the problem of "How does Software A give Software B access to User X's data without Software B having access to User X's login credentials."
The implementation is very much just a standard way for a user to get a token, and then for a third party service to go "yep, this user and this token match, and you can get some of their data from us now."
Fundamentally, though, OAuth 2.0 is just a token protocol. It exhibits the same properties as other token protocols - you still need SSL to protect those tokens - it just changes up how those tokens are generated.
There are two ways that OAuth 2.0 can help you:
Providing Authentication/Information to Others
Getting Authentication/Information from Others
But when it comes down to it, you're just... using tokens.
Back to your question
So, the question that you're asking is "should I store my token in a cookie and have my environment's automatic session management take care of the details, or should I store my token in Javascript and handle those details myself?"
And the answer is: do whatever makes you happy.
The thing about automatic session management, though, is that there's a lot of magic happening behind the scenes for you. Often it's nicer to be in control of those details yourself.
I am 21 so SSL is yes
The other answer is: Use https for everything or brigands will steal your users' passwords and tokens.
You can increase security in authentication process by using JWT (JSON Web Tokens) and SSL/HTTPS.
The Basic Auth / Session ID can be stolen via:
MITM attack (Man-In-The-Middle) - without SSL/HTTPS
An intruder gaining access to a user's computer
XSS
By using JWT you're encrypting the user's authentication details and storing in the client, and sending it along with every request to the API, where the server/API validates the token. It can't be decrypted/read without the private key (which the server/API stores secretly) Read update.
The new (more secure) flow would be:
Login
User logs in and sends login credentials to API (over SSL/HTTPS)
API receives login credentials
If valid:
Register a new session in the database Read update
Encrypt User ID, Session ID, IP address, timestamp, etc. in a JWT with a private key.
API sends the JWT token back to the client (over SSL/HTTPS)
Client receives the JWT token and stores in localStorage/cookie
Every request to API
User sends a HTTP request to API (over SSL/HTTPS) with the stored JWT token in the HTTP header
API reads HTTP header and decrypts JWT token with its private key
API validates the JWT token, matches the IP address from the HTTP request with the one in the JWT token and checks if session has expired
If valid:
Return response with requested content
If invalid:
Throw exception (403 / 401)
Flag intrusion in the system
Send a warning email to the user.
Updated 30.07.15:
JWT payload/claims can actually be read without the private key (secret) and it's not secure to store it in localStorage. I'm sorry about these false statements. However they seem to be working on a JWE standard (JSON Web Encryption).
I implemented this by storing claims (userID, exp) in a JWT, signed it with a private key (secret) the API/backend only knows about and stored it as a secure HttpOnly cookie on the client. That way it cannot be read via XSS and cannot be manipulated, otherwise the JWT fails signature verification. Also by using a secure HttpOnly cookie, you're making sure that the cookie is sent only via HTTP requests (not accessible to script) and only sent via secure connection (HTTPS).
Updated 17.07.16:
JWTs are by nature stateless. That means they invalidate/expire themselves. By adding the SessionID in the token's claims you're making it stateful, because its validity doesn't now only depend on signature verification and expiry date, it also depends on the session state on the server. However the upside is you can invalidate tokens/sessions easily, which you couldn't before with stateless JWTs.
I would go for the second, the token system.
Did you know about ember-auth or ember-simple-auth? They both use the token based system, like ember-simple-auth states:
A lightweight and unobtrusive library for implementing token based
authentication in Ember.js applications.
http://ember-simple-auth.simplabs.com
They have session management, and are easy to plug into existing projects too.
There is also an Ember App Kit example version of ember-simple-auth: Working example of ember-app-kit using ember-simple-auth for OAuth2 authentication.