A friend was not receiving Facebook SMS two factor authentication codes on his iPhone. I removed all his blocked numbers and he received the code. We assume he accidentally blocked the number Facebook uses to send SMS codes.
You can see blocked numbers in Settings:Phone:Blocked Contacts (it's actually a list of blocked numbers, not a list of blocked Contacts). If iCloud sync is working you see the same list in Messages on macOS.
Send an email message to someone who is using Gmail or Google Workspace. (You can't verify DKIM is on by sending yourself a test message.)
In the message header, look for Authentication-Results. Receiving services use different formats for incoming message headers, however the DKIM results should say something like DKIM=pass or DKIM=OK.If the message header doesn't include a line about DKIM, messages sent from your domain aren't signed with DKIM.
When I looked at view original sent form Emily's account to my personal gmail account I didn't see DKIM=pass or DKIM=OK but I did see two entries starting with:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
More importantly when I scrolled up a bit (this is in Gmail View Original) I saw a header that's interpreting the email headers (I think this might be a newer feature):
Message ID ....
Created at: Mon, Mar 13, 2023 at 2:59 PM (Delivered after 12 seconds)
From: Emily ....
To: John ...
Subject: test DKIM content
SPF: NEUTRAL with IP ...
DKIM: 'PASS' with domain ...
You can also paste the "original message" headers into toolbox.googleapps.com/apps/messageheader/. That gave similar results.
When I tested on a second family domain that did NOT have DNS TXT entry for DKIM it showed as DKIM 'PASS" in the email header interpretation with an odd domain string -- BUT in Google Apps it showed as NOT authenticating. I cannot explain this.
Once I updated the DNS TXT DKIM entry for that domain and allowed a few minutes for propagation it did show in the Google Apps admin console as authenticating with DKIM and the headers showed the correct domain name.
DH's note on SPF records says they cannot be updated if we are using Google Workspace. This is new since 2018 and I think that's correct.
Please take these steps to resynchronize the iCloud keychain. Your keychain on iCloud and your other Apple devices won't be affected. Take Step 2 only if Step 1 doesn't solve the problem.Step 1Back up all data.Open the iCloud pane in System Preferences and uncheck the Keychain box. You'll be prompted to delete the local iCloud keychain. Confirm—the data will remain on the servers. Then re-check the box. Follow one of the procedures described in this support article to set up iCloud Keychain on an additional device. Test.Step 2If you still have problems, uncheck the Keychain box again and continue.Triple-click the line below on this page to select it, then copy the text to the Clipboard by pressing the key combination command-C:~/Library/KeychainsIn the Finder, selectGo ▹ Go to Folder...from the menu bar and paste into the box that opens by pressing command-V. You may not see what you pasted because a line break is included. Press return.A folder named "Keychains" should open. Inside it is a subfolder with a long name similar to (but not the same as) this:421DE5CA-D745-3AC1-91B0-CE5FC0ABA128The above is only an example; yours will have a different name of the same general form. Drag the subfolder (not the Keychains folder) to the Trash.Restart the computer, empty the Trash, and re-enable iCloud Keychain.
I pay about $4 or so every month to 1Password because I have not yet been able to replace it. Reason enough to dislike them, but there's worse.
We use 1Password's legacy WiFi sync with 1Password 7. It dates from the days that 1PW was merely mediocre. It was flaky and annoying but it mostly worked. We didn't have to put our lives into the hands of company that could be hacked or acquired at any time (China, Russian ... who wouldn't want those yummy credentials?). Even now that we pay monthly (not yearly, because I plan to leave) we still use WiFi sync.
Every so often we get this:
Every day large numbers of Facebook users receive a message that appears to be from a friend that invites them to click a link. If they click that link their Facebook friends (social graph connections) receive a similar message -- from them.
Many of the victims post on Facebook that their account has been hacked and that recipients should disregard the message. Most change their account passwords, some close their account.
So how does this work?
It's the old "enter password' trick -- a phishing attack. If you click on the link a Facebook screen asks to verify your account identity. This, of course, is a fake page. The credentials you enter there are used to send messages from your Facebook account.
The attackers don't try to change your password, they just send messages to recruit new credentials. There are lots of scams that can be run using Facebook or Instagram messages so this is a profitable business.
Just change your password and try not to be tricked again.
You can't change the date of birth or family relationship of an Apple ID with a calculated age of less than 13 years old. Otherwise it's supposed to be possible to change the date of birth associated with an Apple ID. I've done it before (for good reasons).
Recently I decided to get #2 child an Apple credit card. Since banks take birth dates seriously I decided I needed to correct his before applying. It didn't work!
This is what his birthday looks like on his Apple ID web page (same as in his iOS devices):
In the old days, before family sharing, families shared purchases by sharing an iTunes Apple ID while using their own Apple ID for me.com services.
Now that we've moved to 2FA for iTunes Apple ID there's a new problem with this.
Authentication requests go to one of the devices that uses that shared iTunes Apple ID. Just one. Usually the wrong one.
When my local Apple store tech was unable to remove the battery from my iPhone 8 they gave me a new device -- which was SIM locked to AT&T.
Well, everyone has to start somewhere, including Apple techs. Hope they improve soon.
Anyway, between the initial restore and the factory reset to clear the SIM lock I've been through two iCloud restores in the past week.
iCloud restores kind of suck now. I think they worked better a few years ago. The good news is that my photos were restored (I don't use Apple Photos/iCloud so I needed that backup). The bad news is that so many apps needed credentials reentered or new certificates generated -- especially when doing a restore after a hardware change.
The worst news is that Google Authenticator lost my authenticator codes. As near as I can tell they are restored from iCloud if the hardware is unchanged, but not if the hardware changes. Or maybe it's a bug. Whatever the reason, I lost 'em.
It was suspiciously easy to regenerate Authenticator codes for my Microsoft account. Not too hard for Google either, because they've moved to preferring an Apple-like proprietary two factor authentication mechanism. It is a bummer for Dreamhost though -- so now I'm going through support to try to recover access to my domains and web content.
It's hard to reconcile security and backup/restore. For example, Google Wallet and your biometrics (finger/face) aren't backed up either. On the other hand your Keychain credentials are in iCloud, and anyone who can get into your iPhone can read all of your passwords (try: "Hey Siri, Show me my passwords" or see Apple's hidden password manager). So your 4 digit Apple device passcode is not a great idea.
PS. I'm storing Authenticator codes in 1Password now. Which, like most small company software, has its own security concerns, not least that it would be relatively easy for China, say, to acquire the company or insert a backdoor into the source code.
I think my son installed a "managed by your organization" chrome malware extension when he was trying to find Flash. This one showed in Chrome as "searches.network"
The obsolete Federal government website required for his US census enumerator job probably directed him to get Flash. I wouldn't be shocked if he got the malware directly from the Federal site. US government web sites are notoriously insecure. [1]
This class of malware now works by installing an unsigned profile on the user's Mac that activates Chrome's "managed by your organization" mode. It locks the home page and search page so traffic is routed through the malware's server and it prevents a Chrome reset. (It may do other things as well of course.) For some reason it locked him into Bing, which was a dead giveaway. Smarter malware wouldn't have changed the default search engine.
Once upon a time a quick Google search would have explained how to remove the malware. This is 2020 though, so Google's search results on this topic are mostly garbage. I found one result on a garbage site, however, that must have been partly based on a real site. That clued me to the profile. Once I deleted it then I could do a full Chrome reset. Once I knew the fix I found this guide, which covered the territory. (I can't tell who manages the site, I hope they make money by malware app referrals rather than anything more ominous.)
Before I did this I followed advice from a trusted source and installed the free (but suspiciously marketed) Malwarebyte antiviral. It found nothing. I'll try running one or two more antivirals (AVG, Sophos). Malwarebyte is an easy uninstall, so points for them.
[1] I am the solo family geek, my digital-age children seem to prefer the 18th century. My theory is the latest generation has the same take on computers that, at the same age, I had on automobile engines. It should just work, and if it doesn't work an old person might understand it.
I wrote this up for a book project on special needs iPhone users (Explorers), but it's also my recommendation for non-geek iPhone users. Credential management is definitely an unsolved problem ...
Every Explorer online identity involves, at the least, a “username” for the Explorer, a password and either an iOS app name or a web address (URL). Most online identities also require an email address for communication, password resets and (alas) marketing. They may now require a mobile number and the answers to “secret questions”. All of this information makes up an online “credential”; but we often use the word “password” as a shorthand for the whole bundle
It’s hard to manage online credentials. I’m pretty technical, but I still find it a tough problem. Lots of people get locked out of their online services and need to do password resets or even start over with a new account. One day I think Apple will provide a full solution[1], but to date they’ve been reluctant to take this on.
The good news is that most Explorers can get by with maybe 10-30 credentials and they don’t need to know most of them (more on this below). The key is to use as few online services as possible. Remember, every online service is another credential to manage!
I’m going to suggest three-and-a-half ways a Guide can manage an Explorer’s credentials. Each has advantages and disadvantages. For all of them I have two strongly held recommendations about passwords:
Option One: Pencil and Paper
You may remember being told not to write down credentials on paper. That’s like the old advice to treat back pain with bed rest. We were wrong when we said that. Writing credentials on paper and saving them with your home paperwork is super secure. That’s what hard core security geeks do.
This does require good handwriting, but it works for a small number of credentials assuming you follow my password advice. If you need the credentials when you travel you can take a photo and keep it with your personal iPhone photos (be careful not to share it though!).
You do need a backup! You could copy by hand and mail the copy to a trusted friend. In theory public photocopiers are not secure, so I’d say just take a photo and keep it in your iCloud photos (not shared).
Option Two: Use an iCloud Secure Note on a Guide’s iPhone
I recommend this for the passwords my Explorers manage for themselves. An iCloud Secure Note is protected by both your iPhone’s unlock passcode and by a special Secure Note password. The iOS User Guide explains how to create a Secure Note.
An iCloud Secure Note is automatically backed up and you can review old versions of the note. It can also be shared with an Explorer who is able to manage their own credentials.
This method is less secure than paper and pencil but is also less work — and you can copy/paste passwords from the Note rather than type them on iPhone, Mac, or a web browser[2].
The main risk of this method is accidentally deleting your credentials! Be sure to print out the Note periodically and store the paper copy at home. You can also restore a prior version but this is less reliable. Just print.
Option Three: Use 1Password or another reputable password manager
This is what most computer experts recommend, but true security experts are more cautious. When you use a password manager you are placing a great amount of trust in the vendor. There are so many ways a password manager vendor could steal credentials. Even if a vendor is honest and technically skilled, their products can be acquired by someone less scrupulous.
Of all password managers 1Password is most often recommended for the iPhone. It’s what I use, though I don’t use their Cloud service[3]. The Cloud service is obligatory for most people though, and it costs about $40 a year.
If you’re just managing a few Explorer credentials Paper and Pencil is simpler than a password manager and definitely more secure. If you use a password manager for your own credentials then it may be a good place to store an Explorer’s credentials.
Option Three and a half: Use Apple’s semi-secret password manager
Apple would take over credential management for their customers. It hasn’t happened yet, but they have partial solutions. You can part of Apple’s solution it you have enabled Keychain in Settings:Apple ID:iCloud and you’ve accepted Safari’s offer to save web site passwords. Just say “Hey, Siri, show me my passwords”. You can also go to Settings:Passwords & Accounts: and tap on “Website & App Passwords”.
Another part of Apple’s solution is “Sign in with Apple”. Apple wants iOS apps to support this and there’s a way for web sites to use it as well. This method never shows a password, it works with Face ID or Touch ID[4].
Both of these solutions are a work in progress. We will know Apple is serious if they create a separate App for managing credentials instead of hiding things away in Settings. Not all iOS apps store credentials in the keychain and “Sign in with Apple” is just beginning.
They are convenient for web sites and apps that aren’t important enough to be properly tracked. Just let the iPhone suggest a password and then forget about it. The iPhone will manage the password and if something goes wrong nothing much is lost.
These three-and-a-half options cover Guide management of Explorer credentials. In my next section I’ll go over which an Explorer will need to manage themselves and how to transition from Guide management to independent management.
[1] Apple has a partial solution for web sites but nothing for passwords entered in apps and elsewhere. Their longterm solution is called “Sign In with Apple” but it’s unclear if it will succeed or how serious Apple is about this.
[2] Browsers are not very secure though, so viewing readable passwords in a web browser is not ideal.
[3] 1Password still supports an old local storage method. It requires a very technical user to setup, it’s not well supported any more, and it’s not super reliable.
[4] Since Apple doesn’t support a guest/parent/Guide Face ID this could block Guide support for an app or site. More on this in the final chapter on political action!
When I moved to Mojave I had to give up on my ancient FileMaker Pro database. The modern versions of FileMaker are far too expensive; consumer databases have passed into history.
For lack of a better alternative I moved over to 1Password. I liked them when they worked with a local password store, I’m not keen on their current cloud solution. I just don’t trust their tech.
I exported as CSV as I’d done many times before. This time, though, I ran into a problem that was probably always there. The first time I went to look up my ‘secret question answers’ they were nowhere to be seen. The Login Notes field where I’d imported them was empty on both iOS and mac OS.
Later I realized the data was there — but only in edit mode. If the default read-only view the notes field showed as empty.
It took a bit of playing around to realize what’s wrong.
Text fields in my version of FileMaker, probably from 2014 or earlier, uses the old classic Mac OS line separator - the single “CR” code. It doesn’t use the OS X/macOS/Unix standard LF or the old DOS CR/LF.
When I exported as CSV the output used CR as a separator. When the CSV was imported into 1Password the CR separators went along. They work fine in edit mode but not in view mode.
The proof of the problem was to edit in 1Password, deleting the line feeds and adding new ones. After saving the note displayed correctly.
Update: Per 1Password tech support — turning off markdown formatting causes the notes to appear!
I use a Synology NAS to backup our two MacBooks. I’ve been ignoring it for 4 years, but a recent hardware failure made me look into it.
I found a number of packages installed and/or running that I’d not updated and mostly didn’t need. So I removed all those and I created a reminder to check the NAS quarterly. I also realized I hadn’t gotten monthly status reports for a long time — for years really (if ever)
To enable Synology email status reports you have to configure Notifications. Old-school SMTP is rarely available now, so I experimented with the Gmail option. I got this:
Oookaaay … that’s an interesting range of permissions. Synology is a Chinese corporation, so this effectively gives Xi the ability to harvest my email. Instead I created a synology user on one of my domain based Google Suites and enabled access there then forwarded to my email.
Interestingly my old settings suggested I had gone down the Gmail road at one point. I wonder what I was thinking, in my 2015 post I commented “Synology is a very Chinese product — including off-key English syntax. I wouldn’t install it in a US government facility.” Maybe I started the setup and then stopped?
I bet you didn’t do this [emphases mine]:
…You should also consider verifying an additional phone number you can access, such as a home phone, or a number used by a family member or close friend. You can use this number if you temporarily can’t access your primary number or your own devices….
… To use two-factor authentication, you need at least one trusted phone number on file where you can receive verification codes. Consider verifying an additional trusted phone number other than your own phone number. If your iPhone is your only trusted device and it is missing or damaged, you will be unable to receive verification codes required to access your account…
… If you're signing in and don’t have a trusted device handy that can display verification codes, you can have a code sent to your trusted phone number via text message or an automated phone call instead. Click Didn’t Get a Code on the sign in screen and choose to send a code to your trusted phone number…
Apple 2FA implementation has a high risk of account access loss (Google has better 2FA recovery options). Apple’s recommended mitigation is to use multiple SMS verification numbers, not just the one mandatory number. Since SMS is an essential part of Apple’s 2FA, and SMS is a poor way to do 2FA, Apple’s 2FA is fundamentally insecure (mac bloggers seem universally unaware of this incidentally).
Damned if you do and damned if you don’t. On balance, if you use 2FA, you should have at least two SMS numbers numbers associated with your (insecure) Apple ID.
PS. To Apple’s credit, you need both a password and SMS to access your iCloud account, and you can’t reset the password just using SMS. In the absence of a trusted device the password reset process is mysterious and takes a few days.
PPS. You can use a Google Voice number as a trusted number. That way you can use a web browser to retrieve the authentication code.
When our garage door opener died our service guy installed a LiftMaster Contractor Series Garage Door Opener. I think it’s an 8155W, 8164W or 8165W.
You can enable smartphone app access to monitor and control the garage door — assuming your home WiFi extends that far. Yeah, it’s Internet of Things (IOT) device.
There are obvious problems with doing enabling wifi access:
On the other hand an additional remote is $50 and you can set alarms if the garage door is open after, say, 10pm.
Our garage is not connected to our home, but our Apple AirPort Extreme does reach it. So, despite the risks, I did an initial experimental connection and installed the LiftMaster.app.
It worked ok, so I enabled the Guest network on my AirPort and decided to switch it over. I couldn’t find documentation on how to switch to this network though.
The web page of an error message did give one way to force it to connect:
MyQ Wi-Fi Garage Door Opener: press and release the round yellow Learn button three times on the opener's motor unit. The motor unit's blue LED will be blinking on and off and the opener will beep once.
It turns out there is documentation in the product manual (available online), it just doesn’t contain the keyword “reset”. Instead it uses “erase”. To erase/reset the WiFi network you need to use the controls on the opener, not the remote. There’s an “up arrow” called an “adjustment button”. Press and hold it until 3 beeps are heard. Then start over with the WiFi. (I ran into some issue and Chrome seemed to work around it, so if Safari doesn’t work for you …)
The garage opener is on my Guest network now, so theoretically isolated from my home network.
Dreamhost writes about SPF:
… Mail servers that receive an email for delivery can check SPF by comparing the sending server’s IP address against the email's envelope sender's SPF DNS record. If the email was sent from a server that is not included in that SPF record, the email is more likely to be spoofed or untrustworthy. The receiving mail server may handle the email differently because of the SPF failure, such as marking the email as spam or rejecting the email…
and
What SPF records do I use? – DreamHost
If you’re hosting your email at DreamHost, no changes need to be made to your SPF records. DreamHost’s SPF records are generated automatically and should work without any issues or additional changes.
IP's in DreamHost’s SPF records include mail servers and the relay machine IP addresses.
Except this isn’t true. When I was investigating my family’s Google email Hell I found that emails sent from DH Webmail didn’t have SFP records in the header. I tested using mxtoolbox.com, Kitterman, and by inspecting emails in Gmail using the ‘view original’ option. I also directly inspected my DNS settings. No SFP.
When I asked DH tech support admitted their documentation was wrong and responded (emphases mine):
If it were, you'd see the SPF setup on the 'Manage Domains' > 'DNS' pageby default for every domain hosting mail with us along with the DKIM
that's already there, but SPF is NOT set by default (at this time).
… we should start setting it by default, so that info above may be accurate in the future. We’re doing a lot with emails right now, which is still mostly in the discussion phase, so this is likely something that’ll come up as well what with various hosts starting to strengthen their incoming filters to help stop spam.”For the domain in question, I’ve added the record for you through the 'Manage Domains' > 'DNS' page as a TXT record:
… We have now added the TXT record for .faughnan.com with value v=spf1 include:netblocks.dreamhost.com. Our DNS servers will start serving this
record within a couple of minutes.
My DNS records now show an SFP TXT record:
v=spf1 include:netblocks.dreamhost.com
Unfortunately adding the SPF didn’t help with Google treating my DH redirects as spam. I have a hunch those come from DH’s own SMTP service (homiemail) and that service might have a reputational issue with Google, but I don’t really know what’s going on. I don’t think anyone does any more.
What about DKIM?
DH claims DKIM is set automatically and I can confirm that works, at least for a domain that was relatively recently added to DH. On the other hand when I examine that domain’s DNS settings I see several records not in my older domain. I wonder if DH has never updated DNS settings for older domains, such that they are now obsolete. OTOH, even for a new domain there were no SPF records.
And then there’s Google domain verification (postmaster services). I turned those on my adding their key to a TXT field, but a few days later it wasn’t there any more. I assume DH removed it. I’m kind of losing confidence in Dreamhost.
I wrote this one for Facebook friends - reposting here. The TidBITS review is excellent.
—
This is roughly how things work ...
This happens because your internet provider is your default internet directory service (DNS provider) - Comcast knows all the sites you visit and (as best we can tell) they sell that information.
It's basically an internet design flaw.
If you're a bit geeky you can change the DNS settings in your home router to someone more trustworthy than Comcast (which would be anyone else, really). In our home that's an Apple Airport. I have our settings below but your settings will vary.
We use:
Cloudflare: 1.0.0.1 (their 1.1.1.1 address doesn't work with some ISPs)
Quad9: 9.9.9.9 (as backup)
For more information see an excellent TidBITS review. If you truly want privacy, particularly on iOS where DNS settings are a pain, you need to use a trustworthy VPN (see below).
—
PS. It’s easy in macOS Location settings to experiment with different settings. This is particularly important for a laptop that moves between locations. On my standard macOS Location I use Cloudflare, then Quad9, then Google. Sadly iOS DNS settings are a mess (per TIDBits):
In iOS, DNS server settings tend not to work the way most people would want them, which is as in macOS: setting the details once and having them work on every network to which you connect. The settings have to be set for each network. Worse, we’ve found in our testing that after changing DNS values, the settings revert to Automatic and the server IP addresses we entered are tossed. There’s also no way to set DNS servers for cellular connections.
In iOS you need to use trusted (not free!) VPN provider. I use TunnelBear’s free GB option, I wish I could buy blocks of data from them rather than yet another subscription. If you use a limited data capacity VPN on a Mac you should use TripMode to reduce background data use.
Update 4/22/2018: A Gizmodo article reminded me why this DNS control is more important now ….
“The FCC under Chairman Pai changed the rules in the United States for ISPs allowing ISPs to start selling your browsing history to target advertising against you,” Prince said…
They mention two popular VPNs - ProtonVPN and Private Internet Access. Curiously PIA claims TunnelBear does not protect me — which makes me a bit suspicious of PIA.
I signed up for Instagram before Facebook bought them. Back then it was a curiosity of low value and I used my throwaway password. That’s the password I’ve used for over 20 years for things I don’t care about, usually things that don’t even make it into my 1,867 item password database (ok, so only 488 are likely useful). It’s an 8 character alphanumeric — not bad by the standards of 1997 but obviously insecure now. It’s also certainly been added to many dictionaries as various services have been hacked.
After Facebook acquired instagram I think I authenticated through my Facebook account. I forgot about the old password.
Today when I launched Instagram.app I was notified of a login from Rio de Janeiro. When I answered that was not me I was sent to a password change screen. Evidently, like Google, Facebook/Instagram considers a valid password only a modest marker of identity (it might help that I never use the Instagram password and, in particular, I never login with the email address associated with that account, only with a username).
So no harm there — but it means someone is testing the throwaway password together with my gmail address against a range of accounts. I checked my database and there may be a few low value accounts I should clean up. Very few though …
I got a notice from Google yesterday. tech.kateva.org had been quarantined as a phishing vector. Visitors would be warned away. I had a short time to fix the affected page that was listed below …
But there was nothing there. Same thing with a link to a downloadable spreadsheet of issues. That was empty too.
Elsewhere in the message a page was identified. It sure looked benign, the only link was to an Apple support site. It’s a (Google) blogger site and all the widgets were default Blogger. No extra HTML. No comments.
Also, despite Google’s warning, the blog was not quarantined.
A puzzle.
Oh, I left something out. The day before a published spam comment showed up in my comment tracking feed. I get a few spam comments every day or two, but this was the first published one in a while. I went to delete it … but by the time I got to Blogger’s post management menu the comment was gone.
This is what I think happened:
I changed comments on the blog to require authorization at all times — no two week window for authenticated users. Clearly authentication is no longer a sufficient barrier. I don’t want phishing attacks on my blog, and I don’t want to get quarantined.
This reminds me what a strange fish Blogger is. It works fairly well, though there’s a longstanding problem with CR/LF handling that reminds me too much of DOS 2.1. It gets very few, but still some, updates. Google has switched their blogs off Blogger, but they haven’t used their new proprietary RSS/Blog platform to replace Blogger. Blogger is neither dead nor alive, and Google RSS is similarly quantum.
Wipe that iPhone to give to your child or sell? I’m sure you remembered to launch Google Authenticator and remove the device from your trusted device list before you erased all …
Using a new phone to receive 2-Step Verification codes - Google Account Help
… On your old phone, open the Google Authenticator application…
Oh, you forgot about this step? You are clearly inadequate.
There’s hope though. Assuming you have a computer, there’s another option hidden away …
Add or remove trusted computers - Google Account Help
… Under “Devices you trust,” select Revoke all...
Except that’s not a bit misleading. There are more options once you sign into you Google Account and dig through the “Sign-in & security” section, select Signing in to Google, and Choose 2-step verification.
There you can remove the “Google Prompt” iPhone that manages authentication via Google App. That flips authentication to an Authenticator app (OTP authentication with RFC 6238 and 4226). The Authenticator app might be Google’s, a 3rd party, or 1Password or another password manager. I use Google’s because I started with it and I’m lazy.
You can also “change phone” on Google Authenticator. Authenticator is working for my new device though — which was restored from a 6s backup. So I didn’t do that immediately.
Instead I removed the Google Prompt device, since that was still going to my (since erased) 6s. Then I added it back to my new iPhone 8. Google had the 8’s name so I authenticated there.
Then, because I’m a paranoid sort, once I had Google Prompt working, I went into Authenticator on my i8 and removed my Google account then setup authenticator again from the 2-step verification page (scan barcode).
I’m sure everyone knows to do this. Otherwise why would pundits keep telling us to enable 2FA on every service we care about?
PS. I think when you authenticate within Safari for iOS Google can’t identify the host device. So my https://myaccount.google.com/device-activity list shows both “John8” (my current iPhone) and “Apple iPhone” — even though I believe they are the same thing.
PPS. I think if you want to be very careful you really should do the “Revoke all” as I suspect the old device Safari authentication can still be an issue (except I erased it, but if you’re paranoid …)
See also
