3 ms·

I have a random idea regarding compromised tokens, which may not hold water. What if you put things like the client's IP address in the token? Then the server c

I have a random idea regarding compromised tokens, which may not hold water. What if you put things like the client's IP address in the token? Then the server can reject (and mark for compromise) as soon as they receive any request from a different ip address? I realise this will also invalidate people who somehow roam between ip addressses, say DHCP/wireless in a larger building.

spiffyk 1y ago
More importantly, this will invalidate everyone jumping between Wi-Fi and mobile data, so that might be unworkable for many.
deeringc 1y ago
Enterprise customers often have split tunnel VPNs or proxies (with PAC configs) where part of the traffic may go through a VPN and another part goes directly. So for example a customer admin might configure an app that does email and webRTC so that the real time traffic (media and the associated signalling) goes directly and the email traffic goes via some TLS intercepting proxy for some compliance reason or DLP. This can result in one application having multiple public IPs for different network requests, even while they are on one internal network (not even jumping between networks like you say). That isnt something that the application author can control, it's the customer admin that decides to do that.
hn_throwaway_99 1y ago
Client IP addresses change a lot more than you think, especially on mobile networks.
- alexdbird 1y ago
  Yup. I worked for a media company that made IP part of the access token for media playback. An absolute PITA for the mobile app, and made (reliable) background downloads impossible on iOS. A bad idea. They went out of business.
mooreds 1y ago
There are two in-use RFCs to make compromised tokens much harder to use by attackers. Neither use IP addresses, but both bind the token to the client using some form of cryptography. RFC 8705 section 3[0], binds tokens by adding a signature of a client certificate presented to the server doing authentication. Then any server receiving that token can check to see that the client certificate presented is the same (strictly speaking, hashes to the same value). This works great if you have client certs everywhere and can handle provisioning and revoking them. RFC 9449[1] is a more recent one that uses cryptographic primitives in the client to create proof of private key possessions. From the spec: > The main data structure introduced by this specification is a DPoP proof JWT that is sent as a header in an HTTP request, as described in detail below. A client uses a DPoP proof JWT to prove the possession of a private key corresponding to a certain public key. These standards are robust ways to ensure a client presenting a token is the client who obtained it. Note that both depend on other secrets (client cert, private key) being kept secure. 0: https://datatracker.ietf.org/doc/html/rfc8705 https://datatracker.ietf.org/doc/html/rfc8705 1: https://datatracker.ietf.org/doc/html/rfc9449 https://datatracker.ietf.org/doc/html/rfc9449

spiffyk 1y ago

More importantly, this will invalidate everyone jumping between Wi-Fi and mobile data, so that might be unworkable for many.

deeringc 1y ago

Enterprise customers often have split tunnel VPNs or proxies (with PAC configs) where part of the traffic may go through a VPN and another part goes directly. So for example a customer admin might configure an app that does email and webRTC so that the real time traffic (media and the associated signalling) goes directly and the email traffic goes via some TLS intercepting proxy for some compliance reason or DLP. This can result in one application having multiple public IPs for different network requests, even while they are on one internal network (not even jumping between networks like you say). That isnt something that the application author can control, it's the customer admin that decides to do that.

hn_throwaway_99 1y ago

Client IP addresses change a lot more than you think, especially on mobile networks.

alexdbird 1y ago
Yup. I worked for a media company that made IP part of the access token for media playback. An absolute PITA for the mobile app, and made (reliable) background downloads impossible on iOS. A bad idea. They went out of business.

mooreds 1y ago

There are two in-use RFCs to make compromised tokens much harder to use by attackers. Neither use IP addresses, but both bind the token to the client using some form of cryptography. RFC 8705 section 3[0], binds tokens by adding a signature of a client certificate presented to the server doing authentication. Then any server receiving that token can check to see that the client certificate presented is the same (strictly speaking, hashes to the same value). This works great if you have client certs everywhere and can handle provisioning and revoking them. RFC 9449[1] is a more recent one that uses cryptographic primitives in the client to create proof of private key possessions. From the spec: > The main data structure introduced by this specification is a DPoP proof JWT that is sent as a header in an HTTP request, as described in detail below. A client uses a DPoP proof JWT to prove the possession of a private key corresponding to a certain public key. These standards are robust ways to ensure a client presenting a token is the client who obtained it. Note that both depend on other secrets (client cert, private key) being kept secure. 0: https://datatracker.ietf.org/doc/html/rfc8705 https://datatracker.ietf.org/doc/html/rfc8705 1: https://datatracker.ietf.org/doc/html/rfc9449 https://datatracker.ietf.org/doc/html/rfc9449