- 2FA by default
- Push notifications for the token to all your devices instantly
- Not a text message
- 2FA by default
- Push notifications for the token to all your devices instantly
- Not a text message
... including non-Apple devices.
I've been faffing with this for the past few days - I had to reformat and reinstall OSX on my rather old MBA (2013), and I didn't notice at first, but it only restored Mavericks (was previously Mojave).
As my only Apple device, I was SOL when it asked me enter my verification code for me to log into the App Store to upgrade the OS (as Mavericks is pre-2FA).
There were no other options for verification and the only other device I own is an Android phone (not entirely unreasonable).
I can't see a way round this other than getting ahold of another Apple device to get the code. Am I missing something obvious?
You put in the application, wait about 4 days and then you'll get auto approved (I can't believe any human looked at this process) and you can then set that number as the recovery number.
It seemed to circumvent the whole MFA thing pretty easily but the penalty was time.
No idea what checks were performed in the background by Apple, I suspect none. It seems like the 4 day wait was just to make me feel the system would be secure if someone tried it to me.
On the 2fa front: if you only have one Apple device, you really can't leverage the Apple 2fa system, I think. It always requires a past Apple device of some kind to get the code.
Unfortunately, it doesn't look like you can turn off 2FA once you've had it on for some time, so it feels like I'm being pushed into buying a second Apple device?
Security keys (and the newer project from Google to let your phone act as one over bluetooth) don't have this vulnerability because they connect right to your computer and talk to your browser (and not the attacker's) to verify the domain you're accessing.
How does the security key/browser pair communicate without involving the site? Does it involve more of Google's interference then? While I know you're not saying "yes" to the site, isn't the key doing roughly the same thing?
Right, with Google 2-step verification you don't have to worry about number porting attacks. It's just vulnerable in the sense that a phishing site you've entered your username and password into can still trigger the prompt.
>How does the security key/browser pair communicate without involving the site? Does it involve more of Google's interference then? While I know you're not saying "yes" to the site, isn't the key doing roughly the same thing?
When you use a hardware security key with a browser, your browser tells the security key the page's domain, a user id, and a random challenge token if I remember right. The security key signs a message containing all of these things and gives that back to the browser. If you're on a phishing site, the page will have a different domain than the true site, the message signed by the security key will have the phishing site's domain instead of the true site's domain, and the signed response generated by the security key won't be valid for the attacker to use on the true site.
I'm happy with the security token world. But wish it was more supported for personal things. Yubikey letting me out gpg keys is nice.