Several platforms offer security mechanisms to identify if a user ever logged in from a certain device. If you login from a computer you never did they'll ask you special questions on login. How do they recognize a device? Is this only be geo localization (which would not cover multiple devices in the same region, would it?). Or only with cookies which would cause trouble on cookie cleanup.
As far as I know, cookies is really the only way you can do this. The server stores whatever information it can about your device it can get from the browser in a cookie. By geo-location I assume you mean the location of the IP address.
The ones I've seen do this are all based on cookies and do cause trouble if users delete their cookies.
Doing this by IP address would cause headaches for anyone behind a web-proxy or shared connection. It would also be painful for mobile users in transit where the gateway is changing based on cell tower connections. Geolocation would also present problems for mobile users in transit.
Related
If you log into a platform (Twitch, Blizzard, Steam, Most Crypto exchanges, Most Banks) from a new device you'll typically get an email stating so.
As far as my knowledge goes, the only information you can get on a request is
IP address
Device Operating system & version
Browser type & version
Are these platforms basing their "unique" users off of this information alone and/or am is there more information that can be gathered?
From a security perspective the largest thing is your identity or how you authenticate. That's king. The email stating "hey this is a new device" I've seen handled differently from site to site. Most commonly it's actually browser cache and I see banks specifically use browser cache to store these kinds of tokens. Otherwise every time your cellphone connected to a new cell tower you'd likely be flagged as different. They're not necessarily the same as an authentication token, rather it just says hey I've authenticated as this user to this site before. Since it's generated by the service provider, the service provider knows to trust it, and it's nearly impossible to hack (assuming it's implemented correctly).
From my own experience the operating systems and browser types, that's more record keeping than actionable insights, however you could build a security system that takes into account an IP address from very different geo-locations. I.e. why is this guy from the US logging in from China. They just logged in from California 3 hours ago, this is impossible. I don't believe most sites really go to that extent though. I do see MFA providers saying "hey there's a login from china, do you want to approve?". That workflow makes a lot more sense.
The last part of your question is tricky, regarding "unique users." Most calculate that based off the number of sessions opened (tabs), or in the case of Twitch (since you mentioned them specifically), the number of tabs that are streaming that video in. These open platforms where anyone without an account can stream the content obviously treat this differently than say Netflix that makes you authenticate and each account has a limited number of sessions that can be open.
AFAIK, most of the systems like this stores a cookie in your browser when you log (not the session cookie, just a random ID) that is also assiciated to your account in the provider database, so when you came back, you log in, and they check whether you have that cookie set and in case if the ID matches
They you can probably do some more advance stuff with that ID, like base that value from the browser, OS, expire date and so on
I have cors installed and only my website is whitelisted, how reliable is this? Can bad actors still call my api if they are not calling it from my website?
Next I want to rate limit each user on my website, (the users are not registered or signed in),
I want to restrict each user to make no more than 1 request per second.
How can each user be identified? and then how can each user be limited?
Too many separate questions packaged together here. I'll tackle the ones I can:
I have cors installed and only my website is whitelisted, how reliable is this? Can bad actors still call my api if they are not calling it from my website?
CORS only works with cooperating clients. That means browsers. Your API can be used by anybody else with a scripting tool or any programming language or even a tool like CURL. So, CORS does not prevent bad actors at all. The only thing it prevents is people embedding calls to your API in their own web page Javascript. It doesn't prevent anyone from accessing your API programmatically from whatever tool they want. And, they could even use your API in their own web-site via a proxy. It's not much protection.
How can each user be identified? and then how can each user be limited?
Rate limiting works best when there's an authentication credential with each request because that allows you to uniquely identify each request and/or ban or delay credentials
that misbehave. If there are no credentials, you can try to cookie them to track a given user, but cookies can be blocked or thrown away even in browsers to defeat that. So, without any sort of auth credential, you're stuck with just the requesting IP address. For some users (like home users), that's probably sufficient. But, for corporate users, many, many users may present as the same corporate IP address (due to how their NAT or proxy works), thus you can't tell one user at a major company from another purely by IP address. If you had a lot of users from one company simultaneously using the site, you could falsely trigger rate limiting.
I am building a Web Application using Angular 2 and the backend service built in ASP.NET Core Web API.
For authentication, I am thinking of using JWT and storing the token in a Secure HttpOnly Cookie.
For extra security, I am also thinking of capturing the IP Address for the user on the initial login and on each request after the initial login, revoking the token if the IP Address changes.
So the questions I have are:
Is this extra level of security worth it?
Will there be any problems with the IP check I am thinking of using? Based what I know about networking, I don't think an IP Address will legitimately change between request. Even if it does, I think it would be very rare. However I am not going to pretend I know enough about networking to confirm that.
Edit 1
(In response to an answer).
Thank you for answering my question. I have responded to a few of your responses.
My initial thought was that using JWT in a cookie to connect to an API is not the typical use case, why don't you use a standard MVC app then, but that's not your question and actually it's equally secure as long as the token is in a secure, httponly cookie (and of course the implementation is correct). It's just a bit unusual I think.
I am not sure why you consider using cookies this way unusual?
Is it because most of the time cookies are used for session state? I personally think storing a token in a secure cookie instead of keeping the token in a http header or local storage should be a very typical use case because of how much more secure it is. Unless I am missing something?
So I guess I will ask what is the disadvantage of doing it this way?
It depends. If you are worried about session theft, probably yes. If you keep the token in an httponly cookie (protected against xss), that's more secure than a token anywhere else, but still, your threat model may show different threats and validate your concern. The usual problem is you can't do this, see below.
This application will be dealing with a lot of PPI information so I do have a concern on token theft.
Most probably, there will be problems. It depends on your users, how and from where they use your application. If they use mobile devices, IP addresses will change a lot and such a solution is out of the question. If they are corporate users in a company internal network, it can be feasible. Anything inbetween is a gray area. A typical home user will have their IP changed once in a while, most people get dynamic IP allocation from their internet providers. An IP lease typically lasts a few weeks (at least where I live), but ISPs can configure it any way they want, it can be a day or even shorter.
My impression with IP address lease renew is majority of the time the client gets the same IP address. However I should not make that assumption I suppose?
However I can see this can be more of a problem with mobile devices. Some of the clients will be on the road often so this is a good point you have made that can become a problem.
One typical solution you can choose to do is offer this option on the login screen. If a user chooses to use IP address validation, he opts for greater security but accepts the fact that sometimes he may have to log in again. Or he can choose lower security with his session being more stable. Whether it's worth to explain this to your users is I think a business decision.
Never thought about giving the client an option which does sound like a good idea.
Edit 2
(In response to an answer).
Also I'm not sure whether your JWT only has a session id or if your server is stateless and all session data is in the JWT. In the first case, you don't even need the JWT, you could just pass the session id as normal, and standard .Net MVC does that for you. If it's session data too, JWTs are unencrypted by default, so session contents will be visible to endusers, which may or may not be a problem. (And a JWT is protected from tampering by its signature, so it's only about confidentiality, not integrity). Storing session data in the JWT and the JWT in the cookie may also face cookie size issues, depending on your target browsers.
My backend ASP.NET Core Web API will be stateless. The decision has already been made to use Angular so discussing is a moot point.
As for why I think using a JWT this way is a little unusual: I think JWTs are mostly used when tokens need to be passed to different URLs (to different services). For this purpose, httpOnly cookies are obviously inadequate because of the same origin rule. If you can afford using httpOnly cookies, you could just store your session info on the server side.
A much as I would like to discuss the above topic because my solution could be flawed, I think the powers that be may close this post for getting off topic?
Might be more appropriate to ask a new question targeted toward the above subject?
As for lease renews resulting in the same IP: Well, they don't always. It depends on your business case, but some ISPs give you IPs only for a short time. If it's ok for your users to get logged out once in a while, then it may be ok for wired (home) users. And it is definitely a big problem with mobile devices.
My initial thought was that using JWT in a cookie to connect to an API is not the typical use case, why don't you use a standard MVC app then, but that's not your question and actually it's equally secure as long as the token is in a secure, httponly cookie (and of course the implementation is correct). It's just a bit unusual I think.
On to the point, your question is very valid as is your concern about problems.
Is this extra level of security worth it?
It depends. If you are worried about session theft, probably yes. If you keep the token in an httponly cookie (protected against xss), that's more secure than a token anywhere else, but still, your threat model may show different threats and validate your concern. The usual problem is you can't do this, see below.
Will there be any problems with the IP check I am thinking of using?
Most probably, there will be problems. It depends on your users, how and from where they use your application. If they use mobile devices, IP addresses will change a lot and such a solution is out of the question. If they are corporate users in a company internal network, it can be feasible. Anything inbetween is a gray area. A typical home user will have their IP changed once in a while, most people get dynamic IP allocation from their internet providers. An IP lease typically lasts a few weeks (at least where I live), but ISPs can configure it any way they want, it can be a day or even shorter.
So reality is if you have a normal, usual userbase, you will most probably run into problems.
One typical solution you can choose to do is offer this option on the login screen. If a user chooses to use IP address validation, he opts for greater security but accepts the fact that sometimes he may have to log in again. Or he can choose lower security with his session being more stable. Whether it's worth to explain this to your users is I think a business decision.
Update in response to Edit 1 :)
As for why I think using a JWT this way is a little unusual: I think JWTs are mostly used when tokens need to be passed to different URLs (to different services). For this purpose, httpOnly cookies are obviously inadequate because of the same origin rule. If you can afford using httpOnly cookies, you could just store your session info on the server side. Also I'm not sure whether your JWT only has a session id or if your server is stateless and all session data is in the JWT. In the first case, you don't even need the JWT, you could just pass the session id as normal, and standard .Net MVC does that for you. If it's session data too, JWTs are unencrypted by default, so session contents will be visible to endusers, which may or may not be a problem. (And a JWT is protected from tampering by its signature, so it's only about confidentiality, not integrity). Storing session data in the JWT and the JWT in the cookie may also face cookie size issues, depending on your target browsers.
As for lease renews resulting in the same IP: Well, they don't always. It depends on your business case, but some ISPs give you IPs only for a short time. If it's ok for your users to get logged out once in a while, then it may be ok for wired (home) users. And it is definitely a big problem with mobile devices.
I think you can do it with JWT and IP. When the user logs in. Capture the IP for the length of the session. At every login Capture IP then use that to validate the Token is from the owner who started the session. If another IP hits the system. force a revalidate and new token. IP+JWT+Password = login. If you had mobile apps that required 1 login and always remember the login. User never has to enter login again. Then cache the userid\password in the application {securely} and then resend it automatically when the IP changes. JWT is secure when using SSL Difference between SSL and JWT
Sorry for reviving this, but lately I have been thinking a lot about encryption and security and thought of something (that I guess is pretty similar to what HTTPS does)
When user logs in, the server responds with a normal greeting (user info, JWT and whatever other data you need to pass) + you will pass a public key
Have a backend that supports any asymmetric encryption method (I like RSA) and have your front (also needs to run the same encryption method) end receive the public key, encrypt the data, and send it to the server with every subsequent request.
If any of the data that the user needs to provide changes, revoke.
You can even keep track of a clock, if its off by too much, revoke.
For extra layer, have the client transmit a public key on login/signup and boom, hermetic comms like a hazmat suit.
I have a requirement where an email (or SMS) verification to be obtained whenever a registered user logs into a site using a new device/browser, similar to what Salesforce is doing.
Goal is to reduce the chance of user account being misused by someone, but at the same time it should not become an nuisance to the users.
What are the reliable mechanisms to detect if a request is coming from a new device?
One way would be to use the IPAddress, but that would cause issues when someone's internet connection gets a dynamic IP, and with mobile devices which will get new IPs as they move to new places.
Has the advantage of all browsers on that device (FF/Chrome/IE) are authorized with single confirmation.
Other way is to use a persistent cookie (without sliding expiration), downside is confirmation will have to be repeated for different browsers. (Not a huge issue though, as it's unlikely scenario).
Third option is some kind of hybrid solution of the above two.
My question is, are there accepted mechanisms to do this? What are the reliable ways to detect if someone is using a new device to connect to the site (doesn't have to be bullet-proof though)? Any other advice?
I'd go with the Cookie.
IP addresses are often shared. There's not really a way to identify their computer other than via the browser on the web.
The cookie value should include the username and an HMAC of the username (and probably a nonce too).
After user registers or logs in successfully, send the device cookie. If they are trying to login without a device cookie, they probably haven't used that browser before.
What algorithm or set of heuristics can a server and a mobile app use so that the server can always be fairly certain that the app is used within the boundaries of a given geographic region (e.g. a country)? How can the server ensure that app users outside of the defined region can not falsely claim that they are inside the region?
You can't be 100% sure that user isn't reporting a fake location, you can only make the process of faking it as difficult as possible. You should implement several checks depending on the data you have access to:
1) user's IP address (user can use a proxy)
2) device's gps coordinates (they can be spoofed)
3) the locale of the device (isn't a reliable indicator)
One of the most secure checks (but also not 100%) is sending user an SMS with the confirmation code, which he has to type in the app.
One of the most sophisticated algorithms known to me is in the Google Play (so some apps can only be available only certain countries). It checks such parameters as IP address, user's mobile operator and several others, but there are tools (like Market Enabler) and techniques that can trick the system.
If you dont want to use Google Play or other ways, the best way (I say best because it first costs nothing performance-wise and cost-wise, and secondly it is easy to use and and thirdly you need it anyway if you expect large number of users - it provides nice tools and static cache, optimizer, analytics, user blocking, country blocking etc) is to use cloudflare.
Once you signup for a free cloudflare account, you can set up your server public IP address there so that all traffic is coming through cloudflare proxy network.
After that everything is pretty straightforward, you can install cloudflare module in your server .
In your app, you can get country code of the visitor in the global server request variable HTTP_CF_IPCOUNTRY - for example,
$_SERVER['HTTP_CF_IPCOUNTRY'] in PHP. It will give you AU for Australia. (iso-3166-1 country codes). It doesnt matter what language you use.
Coudflare IP database is frequently updated and seems very reliable to detect user's geolocation without performance overhead.
You also get free protection from attacks, get free cache and cdn features for fast-loading etc.
I had used several other ways but none of them was quite reliable.
If you app runs without a server, you cstill pout a file to a server and make a call to the remote url to get country of the user at each request.
apart from things that #bzz mentioned. you can read the wifi SSID of user wifi networks, services like http://www.skyhookwireless.com/ provides api( i think with browser plugins, i am not sure) which you can use to get location by submitting the wifi SSID.
if you need user to be within specific region all the time when using the app you ll probably end up using all the options together, in case you just need one time check, SMS based approach is the best one IMO.
for accessing wifi SSID , refer to this, still you can not be 100% sure.