What's the Trusted Number for if not to get the verification codes?
Utterly ridiculous. Congrats, Tim, you've given my kid perma-access to her own icloud account, including the RESTRICTIONS.
[Edited by Moderator]
iPhone 7
Congrats, Tim, you've given my kid perma-access to her own icloud account, including the RESTRICTIONS.
You are not speaking with Tim here, or anyone from Apple.
What's the Trusted Number for if not to get the verification codes?
That's exactly what a trusted number is for. Suggests you don't have 2FA set up properly or don't understand how it works.
Her verification codes should go to her phone. 2FA is not managed remotely or by another device.
Congrats, Tim, you've given my kid perma-access to her own icloud account, including the RESTRICTIONS.
You are not speaking with Tim here, or anyone from Apple.
What's the Trusted Number for if not to get the verification codes?
That's exactly what a trusted number is for. Suggests you don't have 2FA set up properly or don't understand how it works.
Her verification codes should go to her phone. 2FA is not managed remotely or by another device.
Published iOS developer here, I know how 2FA works, and I assume the people that wrote the documentation known how it work too.
https://support.apple.com/en-us/HT204915
What you're describing isn't even Two Factors. 2FA is where you specify a second channel (device or account) to prove you have access to that 2nd channel when attempting to access functionality on the primary system. Ignoring the 'trusted number' and sending the verification code to whatever arbitrary primary device happens to be associated with the icloud account is pointless: You only need to possess the primary device to reset the icloud password.
This is akin to writing the combination of a door safe on the door it's affixed to on the theory you can't open the door without the key inside the door safe. Badly broken and ill-conceived if true. Sadly, that appears to be the case.
I developed this app for a financial services company, and yes, it did have 2FA implemented via OAuth.
https://apps.apple.com/us/app/raas-mobile/id1077822248?ign-mpt=uo%3D4
You're correct that the documentation doesn't mention "you only need the primary device to reset the icloud password". That's the whole point. The documentation is obviously wrong since:
1) the trusted phone number DOESN'T receive the verification codes.
2) I was stating a fact, not what the documentation claims: You can ONLY reset the password with the phone number associated with contact method for the id, which isn't 2 Factor at all since possession of the phone (in an unlocked state) is all that is required to reset the icloud password.
3) For what it's worth, the "an additional phone number" refers to secondaries to the trusted phone number. It doesn't imply it IS the trusted phone number, which can readily be identified by the label "TRUSTED PHONE NUMBER" in the "Password & Security" view. Maybe you should brush up on the documentation before you pretend to know it?
Lastly, the plural of "factor" is "factors", and since 2FA requires 2 factors, it is appropriate to refer to it in the plural. Maybe you should read up on what 2FA is before commenting on such things?
https://en.wikipedia.org/wiki/Multi-factor_authentication
And hey, I hope you don't mind I marked all my answers as "Helpful" since you went ahead and marked your non-constructive, totally useless and insulting non-answers as "Solved", when in fact you did no such thing.
published iOS developer here, I know how 2FA works, and I assume the people that wrote the documentation known how it work too.
Please be sure to identify your published app(s) for us. Hopefully they don't require "Two Factors"
You only need to possess the primary device to reset the icloud password.
These words do not appear in your quoted article.
The word "primary" appears once in the article and in the context below.
You have a mistaken impression of what 2FA is supposed to be protecting, it isn't the phone it is your Apple ID and apparently it is working as designed on her phone. Perhaps you should do a little more research before stating your case. Not hard fo find such materials and analysis of 2 Factor Authorization which many companies use in the same manner.
No, that is EXACTLY what I'm trying to protect: her apple id, namely via 2FA with a trusted number for verification purpose, but since the apple id is associated with the primary device the verification goes to the very same device which is 1) Not what the documentation claims. 2) NOT 2FA and 3) incredibly stupid.
Your app has nothing to do with this and doesn't add to your credibility. I think it detracts from it.
You need to re-read that wiki article. You are not understanding the variables of what is being protected vs the authenticator.
Perhaps you're correct, you should really let Google, NXU and everyone who makes a mobile OS and utilizes 2FA. According to you, they're all doing it wrong.
No, Google and Windows and everyone else does NOT do it this way. Their 2FA works just fine because they let you choose from multiple mechanisms and it actually sends the verification code to the mechanisms you configured because it works as documented.
I've written several 2FA systems for various platforms, and the key takeaway from the 2FA wikipedia article is that 2FA refers to an "out of band" method for verifying one's identity via a second channel. Apple's mistake is that it is not sending the verification to the out of band mechanism you are allowed to specify (the "trusted phone number"). Instead it is sending it to the device associated with the account to alter an account that is intrinsic to your use of the device. Requiring access to the primary device is fine if you are protecting the account from unauthorized use on another device or application, but it won't do anything to protect account usage which happens on the primary device.
Common out of band mechanisms such as an RSA fob, or an authenticator app (which, much like an email account, uses separate credentials specific to that app), or Web, Windows, OSX or Google Apps all permit you to specify a band that has no direct connection with the app that is asking for verification. In fact Apple claims the same capability, [that the claimed purpose of a "trusted phone number"] but if you try it, it doesn't work.
So which is it: Did Apple "do it right" and get their documentation wrong, or is the documentation correct and it's just broken?
the trusted phone number DOESN'T receive the verification codes.
You never revealed this before.
you went ahead and marked your non-constructive, totally useless and insulting non-answers as "Solved", when in fact you did no such thing.
I did not and could not do this my friend.
I understand exactly how Apple's implementation of 2FA works.
NotAnAppleFanBoi wrote:
No, Google and Windows and everyone else does NOT do it this way. Their 2FA works just fine because they let you choose from multiple mechanisms and it actually sends the verification code to the mechanisms you configured because it works as documented.
I've written several 2FA systems for various platforms, and the key takeaway from the 2FA wikipedia article is that 2FA refers to an "out of band" method for verifying one's identity via a second channel. Apple's mistake is that it is not sending the verification to the out of band mechanism you are allowed to specify (the "trusted phone number"). Instead it is sending it to the device associated with the account to alter an account that is intrinsic to your use of the device. Requiring access to the primary device is fine if you are protecting the account from unauthorized use on another device or application, but it won't do anything to protect account usage which happens on the primary device.
So which is it: Did Apple "do it right" and get their documentation wrong, or is the documentation correct and it's just broken?
ou went ahead and marked your non-constructive, totally useless and insulting non-answers as "Solved", when in fact you did no such thing.
This is hilarious. I'm out.
I manage my daughter's phone, but requests go to her phone, not the trusted number.
