5 ms·

I'm inclined to agree. I was checking my bank account on my phone yesterday and the office Wifi was having an off day. So I disconnected the wifi and proceeded

I'm inclined to agree. I was checking my bank account on my phone yesterday and the office Wifi was having an off day. So I disconnected the wifi and proceeded to try to login over 4g. I got locked out of my account for 10 minutes because that is suspicious. After checking my account I couldn't find a payment I was expecting to see so I opened my account on my laptop and got locked out for another 10 minutes. Sounds like the dumbest IP checking to me, not some super clever heuristic based check.

heavenlyblue 7y ago
It's that assumption, literally: if the attacker had managed to steal your session information from the browser, then they would not be able to use it since they would also need to share my IP. 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.
- VBprogrammer 7y ago
  The thing is though, what they seemed to object to was trying to login (not using the same session cookie) across different IP addresses. At least that was the case when I opened the site on my laptop. Maybe my phone did login on the dodgy wifi and then when I reconnected via the 4g it tried to use that session, perhaps causing my account to be flagged. I'm not really convinced though. It clearly makes sense to tie the session to the IP address but the 10 minute delay doesn't make much sense to me.
  - nybble41 7y ago
    > It clearly makes sense to tie the session to the IP address... 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.
    - rtkwe 7y ago
      Your IP doesn't change per tower transition, your data from the tower goes through more centralized servers. For example my IP sitting physically in RTP in North Carolina is actually exiting AT&Ts network in Atlanta, Georgia.
      - nybble41 7y ago
        For clean handoffs within the same network, sure. But you also have roaming to consider, and the device may lose its connection temporarily and be assigned a new address when it returns.
        wool_gather 7y ago
        Is there actually any advantage to having a dynamic pool of IP addresses like this? Associating a number from your IP block to a subscriber number seems far, far simpler and better.
        mnoorenberghe 7y ago
        If you’re suggesting each subscriber gets a static IP then that’s much worse for privacy.
        wool_gather 7y ago
        I'm speaking from the provider's point of view: they don't care about privacy. In fact, in the US there is a federal law that requires them to be able to associate network activity with a subscriber at the request of law enforcement.
        zAy0LfpBZLC8mAC 7y ago
        Locality/size of routing tables. If you had a hundred million subscribers with fixed IP addresses moving all over the country, you essentially could not aggregate any routes, but would have to have a hundred million routes in your routing table, and/or you would have to push all the traffic from and to all subscribers through one central router, which in particular would add latency for any subscribers that currenty are at the other end of the country.
- dsfyu404ed 7y ago
  >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. 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.
  - heavenlyblue 7y ago
    Nah, in real life it constantly batters the system administrators with unnecessary alarms who then stop taking them as seriously as they should be if they were actual attacks.
throwaway201606 7y ago
I mentioned signals in another comment in this chain and this is a scenario (for banking specifically) where it makes 100% x 100% sense to kill the session for the client's security. 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.

heavenlyblue 7y ago

It's that assumption, literally: if the attacker had managed to steal your session information from the browser, then they would not be able to use it since they would also need to share my IP. 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.

VBprogrammer 7y ago
The thing is though, what they seemed to object to was trying to login (not using the same session cookie) across different IP addresses. At least that was the case when I opened the site on my laptop. Maybe my phone did login on the dodgy wifi and then when I reconnected via the 4g it tried to use that session, perhaps causing my account to be flagged. I'm not really convinced though. It clearly makes sense to tie the session to the IP address but the 10 minute delay doesn't make much sense to me.
- nybble41 7y ago
  > It clearly makes sense to tie the session to the IP address... 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.
  - rtkwe 7y ago
    Your IP doesn't change per tower transition, your data from the tower goes through more centralized servers. For example my IP sitting physically in RTP in North Carolina is actually exiting AT&Ts network in Atlanta, Georgia.
    - nybble41 7y ago
      For clean handoffs within the same network, sure. But you also have roaming to consider, and the device may lose its connection temporarily and be assigned a new address when it returns.
      - wool_gather 7y ago
        Is there actually any advantage to having a dynamic pool of IP addresses like this? Associating a number from your IP block to a subscriber number seems far, far simpler and better.
        mnoorenberghe 7y ago
        If you’re suggesting each subscriber gets a static IP then that’s much worse for privacy.
        wool_gather 7y ago
        I'm speaking from the provider's point of view: they don't care about privacy. In fact, in the US there is a federal law that requires them to be able to associate network activity with a subscriber at the request of law enforcement.
        zAy0LfpBZLC8mAC 7y ago
        Locality/size of routing tables. If you had a hundred million subscribers with fixed IP addresses moving all over the country, you essentially could not aggregate any routes, but would have to have a hundred million routes in your routing table, and/or you would have to push all the traffic from and to all subscribers through one central router, which in particular would add latency for any subscribers that currenty are at the other end of the country.
dsfyu404ed 7y ago
>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. 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.
- heavenlyblue 7y ago
  Nah, in real life it constantly batters the system administrators with unnecessary alarms who then stop taking them as seriously as they should be if they were actual attacks.

throwaway201606 7y ago

I mentioned signals in another comment in this chain and this is a scenario (for banking specifically) where it makes 100% x 100% sense to kill the session for the client's security. 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.