Add client IP address as criteria for invalidating TFA

Created on 17 November 2022, almost 3 years ago
Updated 28 May 2025, 4 months ago

Problem/Motivation

Apologies if this is already possible but I missed the detail.

A friend's client enquired about resetting the cookie-based TFA recognition if the client's IP address changed. This would be akin to the Google feature where if you log in via a new IP address it asks you to re-authenticate.

Proposed resolution

Provide an option on the TFA Trusted Browser plugin that allows the trust criteria to be invalidated if the visitor's IP address changes.

Remaining tasks

Work out the best solution.
Implement the change.

User interface changes

The "TFA Trusted Browser" plugin would provide an option to control whether the visitor's IP address changing would reset the Trusted Browser system.
If a visitor had trusted their browser but their IP address changed, they would be notified of this and then required to go through the TFA process again.

API changes

TBD

Data model changes

TBD

✨ Feature request
Status

Active

Version

2.0

Component

User interface

Created by

πŸ‡ΊπŸ‡ΈUnited States damienmckenna NH, USA

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States cmlara

    Is there any data around the usefulness of this in the modern world with highly mobile devices?

    My initial gut reaction is "not a bad idea" though my deeper analysis is "how often will site owners actually be able to utilize this?"

    With features such as Apple Cloud Privacy Relay, factored atop rapid cellular IP address changes, it starts to feel like this may not be as useful as it once was as now site owners may expect users to frequently change IP addresses.

    Random IPv6 addresses (where the same device may change its address on its own volition within the same local network assignment) are becoming more relevant now as IPv6 continues to roll out and privacy modes have become the default with the intent to prevent tracking.

    The positive here is this proposal would not result in a user being logged out of their session, just that they would be compelled to provide an OTP again when the session expires.

    The feature concept is initially solid, I just question is there enough user base to justify adding it as code to maintain?

    Using myself as an example:
    I have access to a couple 'stable' IPv4 addresses and IPv6 addresses (not necessarily static though rarely changing) as well a significant number of un-stable addresses (Cellular IPv4 & IPv6, Random IPv6 on networks where I have not disabled wifi privacy). On any given day I cross at least 4 IP addresses on just a single device. I wouldn't be surprised if I routinely crossed through significantly more.

    Factor in network uplink problems (IPv6 down yet IPv4 up or vice versa) and even on a 'static' network with Privacy disabled I can cross through two different IP ranges.

    Not closing the issue as there is room for discussion here.

Production build 0.71.5 2024