Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zero-day in Sign in with Apple

bhavukjain.com

Post reply on HN
Print view View original

171–180 of 280 posts

Re: Zero-day in Sign in with Apple

#171

Post by aidenn0 »

WhyNotHugo wrote: post #131
oauea wrote: post #17

Wow, I'm so glad that apple forced me to implement this broken garbage into my apps! For those not aware, some time ago apple decided it would be a good idea to develop their own sing in system, and then force all apps on their store (that already support e.g. Google Account login) to implement it. So they brought a huge amount of additional complexity in a large amount of apps, and then they fucked up security. Than…

Actually, developers are only forced to implement it _if_ they support logging in with other social auths. A big problem of many apps is that they only had a "log in with google"/"log in with facebook" button, which is very problematic for people who have neither. On Android this is more acceptable since you need a Google account for the OS itself anyway.

But if I support "create an account" and "sign in with google" then you don't need a google account, but still I need to do sign in with apple.

Re: Zero-day in Sign in with Apple

#172

Post by tedunangst »

mlthoughts2018 wrote: post #116
drivebycomment wrote: post #80

Earlier quoted context omitted.

The one case (and about the only case) I can think of where they can claim above is: If they have a log of all JWTs issued that records which user requested and which email in JWT, then they can retroactively check if they issued any (user, email) pair that they shouldn't have. Then they can assert that there was no misuse, if they only found this researcher's attempt.

How could you prove the user was the correct user in any given case?

Assume they have two log entries.

  request 678: request from user bananas
  request 678: issued token for bananas
That looks good.

  request 987: request from user 
  request 987: issues token for carrots
That doesn't look good.

Re: Zero-day in Sign in with Apple

#173

Post by jimsug »

WhyNotHugo wrote: post #131
oauea wrote: post #17

Wow, I'm so glad that apple forced me to implement this broken garbage into my apps! For those not aware, some time ago apple decided it would be a good idea to develop their own sing in system, and then force all apps on their store (that already support e.g. Google Account login) to implement it. So they brought a huge amount of additional complexity in a large amount of apps, and then they fucked up security. Than…

Actually, developers are only forced to implement it _if_ they support logging in with other social auths. A big problem of many apps is that they only had a "log in with google"/"log in with facebook" button, which is very problematic for people who have neither. On Android this is more acceptable since you need a Google account for the OS itself anyway.

> On Android this is more acceptable since you need a Google account for the OS itself anyway.

I don't think you do, I'm pretty sure I've skipped that step during device setup on occasion.

Re: Zero-day in Sign in with Apple

#174

Post by dtech »

thephyber wrote: post #72
zemnmez wrote: post #32

Earlier quoted context omitted.

> I understand why they wanted to modify OAuth 2.0, but departing from a spec is a very risky move. The token described in this disclosure is an OpenID Connect 1.0 Token. OIDC is a state of the art AuthN protocol that supersets OAuth with additional security controls. It's used by Google, Facebook and Twitch amongst others. I'd do more analysis, but the author leaves off the most important part here (not sure why) ht…

The important part is in the author’s article. The POST to the opened endpoint generates a valid JWT token for the email address in the payload, not for the one in the logged-in session. Everything else is extraneous.

That also explains why Apple could exclude abuse happening in the logs, which some commenters have refuted.

If they have all the JWTs, seeing if one had a different e-mail than the logged-in user should be fairly doable.

Re: Zero-day in Sign in with Apple

#177

Post by wmichelin »

earth2mars wrote: post #176

"A lot of developers have integrated Sign in with Apple since it is mandatory for applications that support other social logins" -- How pathetic Apple is to force their own service on developers!!

Why are you surprised? They force you to use the App Store. They force you to process payments through their systems. They force you to comply with many things. How is this any different?

Re: Zero-day in Sign in with Apple

#179

Post by PunksATawnyFill »

mazeltovvv wrote: post #144

This is an amazing bug, I am indeed surprised this happened in such a critical protocol. My guess is that nobody must have clearly specified the protocol, and anyone would have been able to catch that in an abstracted english spec. If this is not the issue, then the implementation might be too complex for people to compare it with the spec (gap between the theory and the practice). I would be extremely interested in…

Let's start with the fact that Apple is forcing people to use an E-mail address as a user ID. That's just straight-up stupid.

How many members of the public think that they have to use their E-mail account password as their password for Apple ID and every other amateur-hour site that enforces this dumb rule?

MILLIONS. I would bet a decent amount of money on it. So if any one of these sites is hacked and the user database is compromised, all of the user's Web log-ins that have this policy are wide open.

Then there's the simple fact that everyone's E-mail address is on thousands of spammers' lists. A simple brute-force attack using the top 100 passwords is also going to yield quite a trove, I'd imagine.

Apple IDs didn't originally have to be E-mail addresses. They're going backward.

Re: Zero-day in Sign in with Apple

#180

Post by sdhankar »

mazeltovvv wrote: post #144

This is an amazing bug, I am indeed surprised this happened in such a critical protocol. My guess is that nobody must have clearly specified the protocol, and anyone would have been able to catch that in an abstracted english spec. If this is not the issue, then the implementation might be too complex for people to compare it with the spec (gap between the theory and the practice). I would be extremely interested in…

The bug is not in the protocol. The bug is about the extra value addition that apple was doing by letting the user choose any other email address. 1. The account take over happens on the third party sites that use the apple login. 2. This seems like a product request to add value to user by providing a relay email address of a user's choice. From the report- `I found I could request JWTs for any Email ID from Apple and when the signature of these tokens was verified using Apple’s public key, they showed as valid.`

It's not a bug with protocol or security algorithm. A lock by itself does not provides any security if its not put in the right place.

Post reply on HN