SoylentNews is people
SoylentNews
What if I say, your Email ID is all I need to takeover your account on your favorite website or an app. Sounds scary, right? This is what a bug in Sign in with Apple allowed me to do.
When Apple announced Sign in with Apple at the June 2019 worldwide developers conference, it called it a "more private way to simply and quickly sign into apps and websites." The idea was, and still is, a good one: replace social logins that can be used to collect personal data with a secure authentication system backed by Apple's promise not to profile users or their app activity.
One of the plus points that got a lot of attention at the time was the ability for a user to sign up with third-party apps and services without needing to disclose their Apple ID email address. Unsurprisingly, it has been pushed as being a more privacy-oriented option than using your Facebook or Google account.
Fast forward to April 2020, and a security researcher from Delhi uncovered a critical Sign in with Apple vulnerability that could allow an attacker to potentially take over an account with just an email ID. A critical vulnerability that was deemed important enough that Apple paid him $100,000 (£81,000) through its bug bounty program by way of a reward.
Considering the level of embarrassment possible for basically leaving the front door unlocked, I'd say the reward was on the light side.
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. This means an attacker could forge a JWT by linking any Email ID to it and gaining access to the victim's account.
(Score: 2) by JoeMerchant on Monday June 01 2020, @07:02PM (1 child)
See also: OAuth2
I need a similar service for a device we're developing - and it took all of an hour to not only sketch out but prototype a functional authentication server proof of concept. After I did that I checked with our "powers that be" and apparently they're using Microsoft's OpenID OAuth2.0 implementation, which may - or may not - provide what I need from an authentication server. If the establishment's server doesn't work with devices the way I want it to, I'll just have to set up a server in the middle that will provide a translation layer at a fixed IP that the OAuth server can call back to.
This stuff is well established, and if you're not totally ADD the specs are about as simple as they come to implement and test. First question: can you get an authorization token without a valid username/password being given to the Auth server? If so: FAIL. How hard is that?
🌻🌻 [google.com]
(Score: 1, Interesting) by Anonymous Coward on Monday June 01 2020, @10:56PM
SQRL is shit for a number of reasons, and isn't a replacement for anything, let alone OAuth2. There is a reason why amateur hour at GRC needed almost 7 years to get it halfway decent. Still doesn't change the broken fundamentals though. It is also a copy of a method created earlier and may actively be covered by patent, but then what do you expect from someone who infamously reinvented a shittier form of SYN cookies and has a history of over promising and under delivering?