In real life if the attacker is capable of stealing my session credentials the chance of them _not_ being able to tunnel through my local network is infinitesimal.
It clearly makes sense to tie the session to the IP address but the 10 minute delay doesn't make much sense to me.
At one point that might have been true but not any more. Mobile devices are the norm, and handoffs between cell towers and WiFi access points are handled transparently without any user interaction. Consequently, people expect their sessions to continue working despite changes in their IP address. Use TLS connections and set expiration times on the session cookies, but ignore the source IP address.
In real life each "trivial" filter like this cuts down a substantial number of potential attackers. Defense in depth. When there's a ton of hoops to jump through attackers go find a different target.
Like kill it totally totally dead!
Unlike other apps, with online banking, the priority is not to keep you connected.
It is to ensure the person carrying out the activity is whom they really say they are and that it is OK for them to do what they are doing with your account
The security posture is "deny" by default and allow if we can verify this person is whom they say they are.
Think about the signals here:
- connection has changed (from wifi to 4g - that gives you a whole bunch of IP, ISP, routing (hops) etc stuff )
- there is a proxy in the chain now (it is possible to identify the hop from phone to laptop)
- view port is still the same (connection is not the user on their phone, they are on their laptop, connected to a phone)
... then the same thing happens all over again but in reverse when you went back to the laptop.
The bank has no idea whether the proxy is a real phone or a MTM intercept especially since the connection did not initiate from that device but switched in flight.
Would totally have required killing the session if I was responsible for defining scenarios here.