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

251–260 of 280 posts

Re: Zero-day in Sign in with Apple

#251

Post by Dahoon »

justapassenger wrote: post #225
ani-ani wrote: post #43

" Apple also did an investigation of their logs and determined there was no misuse or account compromise due to this vulnerability. " Given the simplicity of the exploit, I really doubt that claim. Seems more likely they just don't have a way of detecting whether it happened.

It’s no secret that Apple isn’t great at webservices and they have strong initiative not to keep user data. I could imagine a world where they just didn’t have enough logs to properly investigate and validate it.

> they have strong initiative not to keep user data

What makes you say that? Lots of hacks and leaks shows that Apple only see Privacy as a word to sell stuff. It isn't something they code for if not forced by leaks and hacks (laws in the US also is against privacy by design).

Re: Zero-day in Sign in with Apple

#252

Post by Dahoon »

foobarbazetc wrote: post #112
mormegil wrote: post #101

With all those high-profile third parties using Apple ID, what would happen if somebody stole/deleted/damaged my data/assets on Dropbox/Spotify/Airbnb/...? Would I sue the provider who would sue Apple? But does Apple provide any guarantees to the relying parties? And if not and the only way is to depend on the reputation when choosing the ID providers you want to support, how would anyone want to support Apple ID aft…

The ToS of every service has a liability waiver.

Which doesn't hold in court in most of the civilized world.

Re: Zero-day in Sign in with Apple

#253

Post by afrcnc »

saagarjha wrote: post #196
jedberg wrote: post #195

Earlier quoted context omitted.

That's always true though. 0-day implies it was discovered being actively exploited or that it was released on the 0th day it was discovered.

I believe “0 day” actually refers to the number of days that the vendor has had to fix the issue, not how many days it’s been since it’s discovered. For example, there might be a substantial delay between bug discovery and actual disclosure to the vendor–I usually take a couple days to write up a nice explanation and PoC. If I had found something and then published it publicly the next day without disclosing it, it’d…

It doesn't matter what you "believe"

That's not what that word means. Zero-day refers to actively exploited bugs. Stop hijacking words just to overhype your research.

Re: Zero-day in Sign in with Apple

#255

Post by teknopaul »

I find it crazy that Apple can force devs to support apple id if they support a competing service. The US has gone soft on Monopoly abuse. People have got so used to it they dont notice. Gaping holes in security is only one of the consequences.

Re: Zero-day in Sign in with Apple

#256

Post by hnick »

nine_k wrote: post #207
soonoutoftime wrote: post #202

Earlier quoted context omitted.

Seems the only way to trust the companies in such situations is to exploit the vulnerabilities from multiple, unconnectable devices and locations, over as long a period as possible. If the company cannot list all of the attacks, you know they're bullshitting.

I wonder if compromising your own account can be seen as unlawful. It's much like teenagers being found to break the law by making nude photos of themselves: they are found in possession of prohibited materials, even though they obtained them in a lawful way. Cracking your own account in a lawful way could possibly be done by a court order, but otherwise your actions are prohibited by law, even.though there cannot be…

I think the flaw in this plan is "your own account". AFAIK, like credit cards, the company maintains that they own the account and can do whatever they want with it, just deigning to give you the right to access it as they see fit.

Re: Zero-day in Sign in with Apple

#258

Post by justapassenger »

Dahoon wrote: post #251
justapassenger wrote: post #225

Earlier quoted context omitted.

It’s no secret that Apple isn’t great at webservices and they have strong initiative not to keep user data. I could imagine a world where they just didn’t have enough logs to properly investigate and validate it.

> they have strong initiative not to keep user data What makes you say that? Lots of hacks and leaks shows that Apple only see Privacy as a word to sell stuff. It isn't something they code for if not forced by leaks and hacks (laws in the US also is against privacy by design).

Initiative doesn’t mean they follow it, especially for legacy projects.

While I do think that Apple is using privacy mostly for PR, I wouldn’t be too cynical. It’s likely that new projects are built with higher privacy standards. But also, I wouldn’t be too surprised if their PR department is writing checks that their engineering teams cannot fully cash.

Re: Zero-day in Sign in with Apple

#259

Post by saagarjha »

afrcnc wrote: post #253
saagarjha wrote: post #196

Earlier quoted context omitted.

I believe “0 day” actually refers to the number of days that the vendor has had to fix the issue, not how many days it’s been since it’s discovered. For example, there might be a substantial delay between bug discovery and actual disclosure to the vendor–I usually take a couple days to write up a nice explanation and PoC. If I had found something and then published it publicly the next day without disclosing it, it’d…

It doesn't matter what you "believe" That's not what that word means. Zero-day refers to actively exploited bugs. Stop hijacking words just to overhype your research.

I didn't write the article, so I'm not sure what you mean by overhyping my research. But what you mentioned is referred to as "zero day exploited in the wild"; a zero day doesn't have to actually be actively exploited.

Re: Zero-day in Sign in with Apple

#260

Post by catlifeonmars »

sascha_sl wrote: post #245
catlifeonmars wrote: post #222

Earlier quoted context omitted.

I noticed after reading your comment that HS256 is marked as “required” for compliant implantations. In practice, I have only ever seen signers implement RS256 though...

In OIDC you can actually specificy supported key types in the discovery process and the IdP always decides the key type anyway. HS256 relies in shared secrets, so anyone who can verify a token can also change it. RS256 allows you to download the IdP keychain every once in a while and verify tokens offline.

Yes, that’s what I meant. I only see RS256 implemented by identity providers (and advertised via .well-known/openid-configuration). This makes sense, since most identity providers are decoupled from their clients and thus cannot feasibly share a symmetric key. I am confused what is meant in the JWA specification[1] by “HS256: required” under “implementation requirements” in the table of allowed values (the entry for RS256 reads “recommended” for that column).

[1]: https://tools.ietf.org/html/rfc7518#section-3.1

Post reply on HN