View Issue Details

IDProjectCategoryView StatusLast Update
0003686Composrcorepublic2020-03-18 22:08
ReporterChris GrahamAssigned ToChris Graham 
Status closedResolutionwon't fix 
Product Version 
Fixed in Version 
Summary0003686: More configurability of IP address session locking
DescriptionRather than having a global option about how sessions are restricted to IP address, make it configurable based on usergroup.

Possibilities (in decreasing order of security):
1) Check full IP
2) Check without last octet
3) Check same subnet
4) No check

A session would be restricted based on the highest security usergroup of the user behind that session.
Additional InformationThe problem is some users may be on CGNAT, or TOR, and have wild IP addresses. My view is that we can accept this for non-admins, but for admins we should by default give them extra security (which isn't perfect, but something).

Twitter thread:
TagsRoadmap: v11
Attach Tags
Time estimation (hours)4
Sponsorship open0


Chris Graham

2020-03-18 22:08

administrator   ~0006475

I'm dropping this.

It used to be, and people still believe, that IP addresses are classified as A-E ( However, this has not been the case since the 1990s. ARIN has been supplying IP addresses with much tighter CIDR-ranges to try and preserve space, not supplying based on the original class structure.
So the only way to find what network an IP address is on is to query against ARIN using a whois query - which is against their terms and conditions, and a performance cost.

Then, if a machine is jumping IP addresses in a network, why not across different networks for the same provider (as providers may have many)? So we'd check the "NetName" of the IP address matches rather than the subnet matches.

But if we do that, we definitely lower security.

And anyway, someone may jump different providers entirely, if jumping between wifi and cellular (for example).

The current situation is fine I think. It either checks all 4 IPv4 address components, the first 3, or it doesn't check the IP at all. The admin can decide what security they want.
And if the IP check doesn't match, they aren't logged out - they get cookie login and just need to reconfirm their session to get protected zone access back.

Issue History

Date Modified Username Field Change
2018-09-25 18:55 Chris Graham New Issue
2019-06-27 19:03 Chris Graham Tag Attached: Roadmap: v11
2019-07-12 21:21 Chris Graham Assigned To => Patrick Schmalstig
2019-07-12 21:21 Chris Graham Status non-assigned => assigned
2020-03-07 21:25 Chris Graham Assigned To Patrick Schmalstig => Chris Graham
2020-03-18 22:08 Chris Graham Status assigned => closed
2020-03-18 22:08 Chris Graham Resolution open => won't fix
2020-03-18 22:08 Chris Graham Note Added: 0006475