Apple's “iCloud Private Relay” broke risk based authentication • Hacker News Board

Re: Apple's “iCloud Private Relay” broke risk based authentication

#51

Post by ffo » Wed, Jul 07, 2021, 3:41 PM UTC

md_ wrote: post #49

SahAssar wrote: post #11

Earlier quoted context omitted.

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.

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.

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.

Re: Apple's “iCloud Private Relay” broke risk based authentication

#52

Post by csunbird » Wed, Jul 07, 2021, 3:44 PM UTC

snowwrestler wrote: post #50

csunbird wrote: post #4

> As of writing this blog I was in Switzerland and the IP used to egress my traffic was in a region located in the US. If this also tends to change a lot and fast you can basically throw away IP addresses as data of your RIBA. Wait, so my data will be routed to US servers, as an EU resident, where the data protection laws are not as strong as where I live? This is a really bad idea, as US is known to tap any data the…

You have no control where your packets get routed on the Internet, by design of the basic protocols. Personal data should be protected by TLS (edit: and/or application-level encryption) so packet routing is irrelevant to privacy and data protection. I am very worried that the demand for protection of personal data (which is good) is mutating into an expectation of fully regional Internets that do not peer with each o…

It is easier for US to ask Apple to monitor the traffic for a specific user, if the exit node is in US soil. Although the sibling comments say that it is probably a bug, and I hope that it actually is.

Re: Apple's “iCloud Private Relay” broke risk based authentication

#53

Post by kstrauser » Wed, Jul 07, 2021, 3:44 PM UTC

jarym wrote: post #2

"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.

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.

Re: Apple's “iCloud Private Relay” broke risk based authentication

#54

Post by avh02 » Wed, Jul 07, 2021, 3:46 PM UTC

james_pm wrote: post #34

We're anticipating having to make some changes to our fraud scoring which uses things like location vs. credit card address as signals.

as someone who lived abroad but had a US based account i wanted to use to buy things with - "clever" moves like this were the bane of my existence.

Combine that with a bank that would freak out if you used the account from abroad it was often a multi-day operation to get a transaction to go through (between support calls to bank and merchant)

Though i guess a signal vs hard lock/logic.

Re: Apple's “iCloud Private Relay” broke risk based authentication

#55

Post by md_ » Wed, Jul 07, 2021, 3:48 PM UTC

ffo wrote: post #51

md_ wrote: post #49

Earlier quoted context omitted.

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.

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 w…

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.

Re: Apple's “iCloud Private Relay” broke risk based authentication

#56

Post by TurningCanadian » Wed, Jul 07, 2021, 3:51 PM UTC

Did it actually break risk based authentication though? Sure, legitimate users will be using Apple's Relay, but what's stopping attackers from using it? If the users of the service are choosing to be indistinguishable from attackers, then that's on them.

I think of it like reputation in real life. If you come knocking on my door, and I can see and recognize you, I'll open it. If you cover up my peephole or hide yourself so that I can't recognize you, why would I even let you know I'm home? Even if you tell me who you are, shouldn't I be worried that someone is impersonating you?

At the very least I'd expect users from anonymizing IPs to have to jump through some extra hoops like captcha and 2FA.

Re: Apple's “iCloud Private Relay” broke risk based authentication

#57

Post by dividedbyzero » Wed, Jul 07, 2021, 3:53 PM UTC

snowwrestler wrote: post #50

csunbird wrote: post #4

> As of writing this blog I was in Switzerland and the IP used to egress my traffic was in a region located in the US. If this also tends to change a lot and fast you can basically throw away IP addresses as data of your RIBA. Wait, so my data will be routed to US servers, as an EU resident, where the data protection laws are not as strong as where I live? This is a really bad idea, as US is known to tap any data the…

You have no control where your packets get routed on the Internet, by design of the basic protocols. Personal data should be protected by TLS (edit: and/or application-level encryption) so packet routing is irrelevant to privacy and data protection. I am very worried that the demand for protection of personal data (which is good) is mutating into an expectation of fully regional Internets that do not peer with each o…

If personal data from EU citizens is routed through the US in the clear or in a decryptable form, that's probably forbidden under the GDPR. There are exceptions, but this doesn't look like one of these.

And while I may not have direct control over where my data is actually routed, but there absolutely are legal restrictions on where companies may route them.

Re: Apple's “iCloud Private Relay” broke risk based authentication

#58

Post by ffo » Wed, Jul 07, 2021, 3:56 PM UTC

md_ wrote: post #55

ffo wrote: post #51

Earlier quoted context omitted.

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 w…

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.

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 ;-)

Re: Apple's “iCloud Private Relay” broke risk based authentication

#59

Post by SahAssar » Wed, Jul 07, 2021, 4:06 PM UTC

md_ wrote: post #49

SahAssar wrote: post #11

Earlier quoted context omitted.

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.

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.

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.

Re: Apple's “iCloud Private Relay” broke risk based authentication

#60

Post by cratermoon » Wed, Jul 07, 2021, 4:07 PM UTC

TurningCanadian wrote: post #56

Did it actually break risk based authentication though? Sure, legitimate users will be using Apple's Relay, but what's stopping attackers from using it? If the users of the service are choosing to be indistinguishable from attackers, then that's on them. I think of it like reputation in real life. If you come knocking on my door, and I can see and recognize you, I'll open it. If you cover up my peephole or hide yours…

It broke it in the sense that it removed a signal that would allow the service to distinguish legit users from possibly malicious ones. In the case of a legit user that has in the past always authenticated from an IP address or address block geolocated to say, Seattle, the service can look at any authentication attempt from elsewhere as anomalous and raise additional challenges.

However, with Relay, that signal is lost. Legit users and malicious parties become indistinguishable. The service can't tell if traffic from the relay is from a customer or an attacker.

What to do? Trust everything? Not good. Treat everything as potentially malicious? Safe, but makes the user experience worse.

To use your analogy, if you look through your peephole and can't tell if the person is your best friend or your worst enemy, how do you react? If you assume it's your best friend, you could be in trouble. If you treat the visitor like your worst enemy, you've pissed off your best friend.