Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security Apple

OpenID Foundation Says 'Sign In with Apple' is Not Secure Enough (zdnet.com) 39

Posted by msmash from the closer-look dept.
The OpenID Foundation, the organization behind the OpenID open standard and decentralized authentication protocol, has penned an open letter to Apple in regards to the company's recently announced "Sign In with Apple" feature. From a report: In its letter, the organization said that Apple has built Sign In with Apple on top of the OpenID Connect platform, but the Cupertino company's implementation is not fully compliant with the OpenID standard, and as a result "exposes users to greater security and privacy risks." "The current set of differences between OpenID Connect and Sign In with Apple reduces the places where users can use Sign In with Apple and exposes them to greater security and privacy risks," said Nat Sakimura, OpenID Foundation Chairman.

The OpenID Foundation published a list of differences between Sign In with Apple and the OpenID Connect platform, which Sakimura urged Apple to address. The OpenID exec said these differences place an unnecessary burden on developers working with both OpenID Connect and Sign In with Apple, who now have to support two different authentication standards and deal with each one's quirks. "By closing the current gaps, Apple would be interoperable with widely-available OpenID Connect Relying Party software," Sakimura said.
This discussion has been archived. No new comments can be posted.

OpenID Foundation Says 'Sign In with Apple' is Not Secure Enough More

OpenID Foundation Says 'Sign In with Apple' is Not Secure Enough

Comments Filter:

  • PGP/GPG with password-based key manager (Score:1)

    by Anonymous Coward

    That's the only way. Passwords should be for local maintenance of your cryptographic keys.

    That being said, websites should allow each user to specify multiple keys for login (like having multiple passwords). That way, a user doesn't even need to move private keys between devices—a user just generates a private key on each device, and maybe uses a transient password/2fa means by which to register it with the service in question.

    Of course, if a user wants to transfer a private key around, that should be

  • If Apple cared about interoperability (Score:5, Insightful)

    by cdsparrow ( 658739 ) on Thursday July 04, 2019 @11:25AM (#58872928)

    They would have just made it work with openid connect. Probably took more work to break interoperability, so was likely on purpose...

    • Re:If Apple cared about interoperability (Score:4, Interesting)

      by Antique Geekmeister ( 740220 ) on Thursday July 04, 2019 @12:56PM (#58873352)

      It sounds similar to what Microsoft did with Kerberos, the authentication protocol used by Active Directory. MIT Kerberos was and is completely open source. Microsoft extended certain standards and make it incompatible with MIT Kerberos servers. Some of the distinctions and standards violations are documented at https://www.usenix.org/techses... [usenix.org] . Fortunately, the administrators of MIT Kerberos were able to quickly adapt their code to enable compatibility with Microsoft's extensions: this would not have been possible with a vendor manipulated, closed source software base and API.

      Is there a similar document for this Apple vs. OpenID incompatibility?

  • The referenced list of problems (Score:5, Informative)

    by Anubis IV ( 1279820 ) on Thursday July 04, 2019 @12:15PM (#58873182)

    You have to go through three links to find the actual list of concerns that's referenced in the summary [bitbucket.org]. I'll save you the time of tracking down the links. Some of the high points:

    Spec Violations

    • When nonce is provided in the code or code id_token grant types, it isn’t included in the id_token returned.
      • Not having the nonce removes the protocol's ability to thwart Cross Site Request Forgery Attack.
    • The code id_token response type does not include c_hash in the returned id_token.
      • It makes it possible for Attackers to insert the authorization code they have obtained (Code Insertion Attack).
    • The code id_token response type returns the response parameters including id_token and code as query parameters, not in the fragment.
      • It makes ID Token and Authorization Code potentially leak through referrer etc. ID Token is a set of personal data and leaking it will pose privacy risk. An authorization code obtained by the attacker in this way may be used for the Code Insertion Attack.
    • Providing a prompt parameter with any value (e.g. login or consent) or empty results in a 400 with no body.
      • Not being able to ask for explicit consent increases the privacy risk for end users.
    • When max_age is requested, the id_token does not include an auth_time claim.
      • The Client may want to limit access to protect the user if the authentication at the Provider was done too long ago but the lack of support for max_age does not allow for such a decision.

    There's more at the link, so go there if you're interested in seeing "peculiarities", things Apple has already fixed, and other details.

    • Sounds somewhat loosely analogous to when Microsoft rewrote its TCP stack to remove the BSD code - they basically ended up having to re-learn a lot of security lessons the BSD folks had learned (and addressed) years before. Here, Apple will likely be rediscovering security lessons the OpenID folks already figured out.

      But it's not like Apple is doing anything wrong. OpenID has a pretty permissive license [openid.net] which basically says "do what you want with our code, as long as you give us credit". And OpenID isn't co

  • "By closing the current gaps, Apple *would be interoperable* with widely-available OpenID Connect Relying Party software" Considering their history, at Apple the lack of interoperability is considered the most important feature.

Slashdot Top Deals

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Close