I was thinking about how to secure my API and prevent token theft from affecting my users. I thought it would be a good idea to save my users IP if an attacker manages to steal a token and is used by one with a different IP. I'm going to use a middleware or a function to verify if it is in the user ip list and if not I'm going to reject his token and then ask for your credentials in the frontend. If the credentials are correct I will overwrite the IP or store it as a new one.
I don't know exactly what you mean by "is it feasible". Yes, you can do it if you want.
But, there are plenty of potential issues with relying on a user's IP address not changing and forcing them to reauthenticate every time it does change.
1. Mobile devices moving around. As mobile devices move on a cellular network, their IP address can legitimately change.
2. Mobile devices connecting to different networks (such as WiFi). As your phone goes from being in your car and on the cellular network to being at home and on your WiFi network, that phone's IP address in connecting to your service will change.
3. NAT behind some firewall. Nearly every user (even home users) are going through a NAT device and the IP address you're seeing is the IP address of a gateway, not the actual user's IP address. In a larger corporate network, the gateway IP address may not always be the same. And, multiple different users may appear to be from the same gateway IP address so there is not necessarily a one-to-one correspondence between users and IP addresses.
In general, you should just be using https for all connections in which you transmit the JWT so there is little risk of man-in-the-middle attacks stealing the JWT. The user themselves needs to secure their own local storage of the JWT.
An approach used by many modern services is to fingerprint the local device by recording a set of characteristics it has which may even include the presence of some other cookie along with a number of other browser characteristics. Then, you require reauthentication whenever the fingerprint changes by some significant amount. You will see many bank and airline websites doing something like this. The idea here is that even if the credential is stolen, then the fingerprint is unlikely to match when a credential is being used by an attacker.
Related
In some countries like Iran or china because of severe Internet censorship, people use a foreign VPN server to bypass government censorship.
Imagine we implement a none-SSL VPN for people who connect their phone to the Internet through this VPN. I want to know if they use a secure application within their phone which is secured by SSL like Instagram or WhatsApp, still, is there any security issue for the transmitted data between their phone and server?
I mean is it possible in this case their data would be sniffed by the government or others? (although the VPN is none-SSL but Instagram is SSL secured)
If I understand the scenario you have described, the VPN does not use SSL when communicating with the user device, but the secure application requires the use of SSL between the server and the client device.
The answer would depend on a few more things. Does the "severe internet censorship" flat out restrict the usage of the application? Take Instagram for example. Is the government banning the use of the application in its entirety or just certain aspects (such as filtering specific tags)? Sometimes the term "internet censorship" is used to mean one of these things but not the other (though most often the former).
Assuming the application is banned in its entirety, and the connection to the VPN is not secured by SSL, then the domain which is being banned would be visible to eavesdroppers at some point prior to the secure channel establishment (with SSL or rather TLS) between the client device and server. For example, it is likely the case that the DNS resolution of the domain is unencrypted (either at the client device level or communicating the query to the VPN). So, the eavesdropper (say, the government) would be able to see this and possibly act on it (say by dropping the request if they have a middlebox unknown to you).
So basically, if the connection to the VPN is not secured by SSL (or TLS) then there would be no benefit in using the VPN with regards to censorship.
I'm behind a company firewall and have been asked to share my IP address in order for me to be white-listed so can access an API. This is first time I've been asked for this and find it uncommon ? as usually I connect to an API via OAuth or access token, https username password etc. Is this a safe way to access an API, will I creating any security risks though sharing my IP ?
Update :
The API host is asking for my IP.
You give your (external) IP address to every single website you visit. It's ok to let them strengthen access control by IP restriction.
However, if that is the only security measure (as opposed to proper authentication and access control), that's not OK, especially not in a corporate setting, where everybody behind your firewall will have the same external IP address because of NAT (and even if it's not the case, there must be proper authentication on a secure API).
My web app is using a 3rd party tool for storing sensitive data, which has the ability to send events via a callback url (i.e. when something changes it will make a request to the given url). In order to prevent malicious requests the 3rd party tool suggests checking the IP Address of the request to ensure that it came from their server, but this seems like it would be vulnerable to spoofing.
Questions:
Is it safe to validate origin of requests in this way?
Would client certificates be a more reasonable approach for them?
If the 3rd party app is across the internet, then your check would be protected against IP spoofing as the 3 way handshake cannot take place if the IP address is spoofed. (Discounting large scale attacks such as IP hijacking.)
If the 3rd party app is on another server within your local network, then another user on that network could just set their local IP to that of the app to spoof it.
To summarise:
Could a web app which authenticates a client only by IP address be exploited?
No - if the app is internet based, the risk of IP spoofing is very low.
As part of strengthening session authentication security for a site that I am building, I am trying to compile a list of the best ways to register a user's computer as a second tier of validation - that is in addition to the standard username/password login, of course. Typical ways of registering a user's computer are by setting a cookie and or IP address validation. As prevalent as mobile computing is, IP mapping is less and less a reliable identifier. Security settings and internet security & system optimization software can make it difficult to keep a cookie in place for very long.
Are there any other methods that can be used for establishing a more reliable computer registration that doesn't require the user to add exceptions to the various cookie deleting software?
If you're looking to do device authentication, you may want to consider mutually authenticated SSL. Here, you'd deploy a client identity certificate to each endpoint you'd want to authenticate. Then, you set the server up to require client authentication, so that a client would need to present a valid identity certificate in order to form the SSL tunnel.
This, of course, is not a perfect solution. In reality, this presents much of the same weaknesses as other solutions (to various degrees) Once your client identity certificates go to your clients, they are out of your control; should a client give their certificate to anyone else, you lost the device authentication that you have based on it. SSL identity certificates are generally stored in a keystore on the client which is encrypted with a password or other credential needed to unlock them. While a client certificate could still be compromised, it's somewhat stronger that just a cookie or something like that (assuming you don't have a client that is trying to give away its credential). In addition, you'd want to come up with some validation routine that a client would need to go though in order to get a credential in the first place (how do I know that this is a client device that I want to remember/register?).
Remember, these types of approaches only do device authentication, not users. There are more in-depth schemes already developed for device authentication than what I've mentioned; for example, 802.1x is a network protocol where an endpoint needs to present a client-side certificate to the network switch to get on a LAN. This is out-of-scope for a web application scenario, like what you've described, but the idea is the same (put a cryptographic credential on the client and validate it to establish the connection).
This, like all other security matters really, is a risk decision. What are you trying to accomplish with such a countermeasure? What are the threats you're trying to prevent and what are the consequences if someone does log in on an unregistered device? Only your situation can answer those questions and let you see the real risk, if you need/should mitigate it, and, if so, how strong of a solution do you need to get the risk level down to an acceptable level?
the best ways to register a user's computer as a second tier of
validation
From my point of view this approach does not offer much in the aspect of authentication.
You are not authenticating a user and have no idea who is using the PC that you would accept as being registered.
The way you describe it, this step should be a configuration rule in the firewall to accept connections from specific IPs only.
IMO the filtering of the PCs is the responsibility of a firewall and it would be much better handled by the firewall than any application level filtering.
Just think that you would have the overhead in your application to examine each request and decide whether to accept it or not.
Better leave this preprocessing overhead to the firewall. That's why it is there.
So, note that this is not about browser-server communication. In server-to-server communication, would using the other server's IP address to make a request, as opposed to using its host name, reduce the likelyhood of MITM attack?
If you have all Systems (including DNS) under your control, use the Domain Name. The risk for MITM attacks via DNS are as high as MITM via IP Spoofing. But you could move an application much better. You could just move the Domain Name.
If you have a valid, public signed SSL cert, you have the benefit that you don't need to buy a new one, if the IP changes.
If you don't have control over the other side, and worry about MITM: Don't connect to the system!