4 ms·

"But please stop relying on RIBA for the plain authentication of a user!" Well I'm not sure everyone will be happy to do that. Tying session tokens to source

by jarym 5y ago

"But please stop relying on RIBA for the plain authentication of a user!" Well I'm not sure everyone will be happy to do that. Tying session tokens to source IP addresses is usually not a bad practice and is rarely the only mitigation used.

ffo 5y ago
Well, in the end channel binding would be the best option which really mitigates some threat vectors. For example MITM, secrets extraction out of the browser and so on. But the big issue is that this is not widely supported. Using the IP as means is IMO nonsense with todays use of CG-NAT, VPN and so on. It does not rely help securing something. But these are just my 2 cents ;-) Disclaimer: I wrote the article
SahAssar 5y ago
Token binding was a much better way to do this where you'd bind a cookie to a certain client TLS key. Unfortunately only MS implemented support, and that disappeared when they moved to chromium so I'm guessing it's dead.
- ffo 5y ago
  I think it is still there, even in Edge on Chromium. But still Chrome dropped the hidden support a while ago.
  - SahAssar 5y ago
    Every source I could find said that it was not carried over to chromium-edge and considering how little use it got (because of poor browser support) I'm not surprised.
    - ffo 5y ago
      Ok, maybe I remembered wrong. This makes things even worse.
- md_ 5y ago
  Hmm, I'm not convinced it's better—but it depends a lot on your threat model. For preventing malware from using stolen cookies on a botnet, it's reasonable to argue that it's easier for the malware to steal the TLS client cert (which is no less accessible than the cookie jar itself) than it is for the malware to maintain access to the "good" client IP. As silly as IP-binding of sessions is.
  - ffo 5y ago
    To use ip binding as means already fails today. I mean CG-NAT and the slow adoption of ipv6 also did help dig that grave and I would argue that with that you can't rely on the IP because it is volatile anyway. From a threat model perspective it is absolutely true that when attacker gains control over the device they could extract the secrets from that said device (they can act as you as well). However token-binding would at least allow for some safeguards against attacks from the application layer (in this case web apps and extensions) in the browser but not against device attacks.
    - md_ 5y ago
      Agreed. And TB arguably could have supported hardware-backed key storage—but no implementations I am aware of did this. My point was only that lamenting the demise of TB as implemented is a bit overdramatic. Lamenting the demise of TB as (perhaps) dreamed about—yeah, I buy that.
      - ffo 5y ago
        Totally agree with your point here. Would love to see a TB implementation depending on hardware keys. But yeah it is gone. If the UX for mTLS (client certs) just was not so terrible it might be a great alternative with even better Security, but that is a dream as well ;-)
  - SahAssar 5y ago
    It can be made much less accessible because it's not meant to be shared with the remote side. A client cert is also not shared among all users behind a NAT, can be durable across roaming across IPs, and is actually meant to be a security measure unlike IPs.
kstrauser 5y ago
That’s a great practice as long as zero of your users are on phones — which will generally be the case if you deauthenticate them every time their IP changes and they stop using your site.

by jarym 5y ago

ffo 5y ago

Well, in the end channel binding would be the best option which really mitigates some threat vectors. For example MITM, secrets extraction out of the browser and so on. But the big issue is that this is not widely supported. Using the IP as means is IMO nonsense with todays use of CG-NAT, VPN and so on. It does not rely help securing something. But these are just my 2 cents ;-) Disclaimer: I wrote the article

SahAssar 5y ago

Token binding was a much better way to do this where you'd bind a cookie to a certain client TLS key. Unfortunately only MS implemented support, and that disappeared when they moved to chromium so I'm guessing it's dead.

ffo 5y ago
I think it is still there, even in Edge on Chromium. But still Chrome dropped the hidden support a while ago.
- SahAssar 5y ago
  Every source I could find said that it was not carried over to chromium-edge and considering how little use it got (because of poor browser support) I'm not surprised.
  - ffo 5y ago
    Ok, maybe I remembered wrong. This makes things even worse.
md_ 5y ago
Hmm, I'm not convinced it's better—but it depends a lot on your threat model. For preventing malware from using stolen cookies on a botnet, it's reasonable to argue that it's easier for the malware to steal the TLS client cert (which is no less accessible than the cookie jar itself) than it is for the malware to maintain access to the "good" client IP. As silly as IP-binding of sessions is.
- ffo 5y ago
  To use ip binding as means already fails today. I mean CG-NAT and the slow adoption of ipv6 also did help dig that grave and I would argue that with that you can't rely on the IP because it is volatile anyway. From a threat model perspective it is absolutely true that when attacker gains control over the device they could extract the secrets from that said device (they can act as you as well). However token-binding would at least allow for some safeguards against attacks from the application layer (in this case web apps and extensions) in the browser but not against device attacks.
  - md_ 5y ago
    Agreed. And TB arguably could have supported hardware-backed key storage—but no implementations I am aware of did this. My point was only that lamenting the demise of TB as implemented is a bit overdramatic. Lamenting the demise of TB as (perhaps) dreamed about—yeah, I buy that.
    - ffo 5y ago
      Totally agree with your point here. Would love to see a TB implementation depending on hardware keys. But yeah it is gone. If the UX for mTLS (client certs) just was not so terrible it might be a great alternative with even better Security, but that is a dream as well ;-)
- SahAssar 5y ago
  It can be made much less accessible because it's not meant to be shared with the remote side. A client cert is also not shared among all users behind a NAT, can be durable across roaming across IPs, and is actually meant to be a security measure unlike IPs.

kstrauser 5y ago

That’s a great practice as long as zero of your users are on phones — which will generally be the case if you deauthenticate them every time their IP changes and they stop using your site.