Month: December 2025

Disney runs quite a few properties including disneyplus.com, hulu.com, espn.com, abc.com, and a bunch of obviously Disney sites like shopdisney.com, disneyworld.disney.go.com, and disneycruise.disney.go.com. They have a centralized authentication system so all of these sites can use the same email address and password to log in.

It has a couple major problems though:

1. It isn’t obvious that the login is shared. They share a logo when logging in, but its not obvious to users that these sites share the same credentials. I wouldn’t expect that espn.com uses the same login as hulu.com and I know that Disney owns both of them! Also, password managers aren’t aware that the logins are tied together, so when you log in to one site and your password doesn’t work because you don’t realize they are shared, you end up resetting it. And then it broke your password for another site that you didn’t realize was connected
2. Users can’t verify that a site is legitimate. It would be trivial for an attacker to create a fake Disney site and mimic the Disney login system to capture passwords. I actually noticed this because my wife was logging into a site for Disney gift cards and I seriously throught it was a scam

Disney should implement a shared login that uses a common login site (like login.disney.com) so that users can know that it is a legitimate Disney site. This fixes the issues above. Users can know that they trust login.disney.com. Password managers will use the same credentials. And it will be more difficult for attackers to mimic a site if users know that login.disney.com is the only legitimate place to log in

Lots of services need to validate ownership of a domain. Especially for sending email or creating SSL certificates

Creating a TXT record at the domain root (@) is a common practice and I think it should be avoided. Many services like to request adding things to this same record. That creates several concerns:

1. It leaks information about what 3rd-party services you use (or have used). This is a minor security issue, but is not necessary
2. The process for adding multiple lines to a single records is inconsistent between various services, meaning that instructions have to be service-specific. Instructions for GoDaddy are different than on CloudFlare
3. Most services don’t have comments on DNS records, and the names of the records are often not self-explanatory. You end up with many lines and don’t know which is for which service. To make matters worse, records are rarely removed when you stop using a service, so it becomes an ever-growing list

A better practice is to use either TXT or CNAME records for specific hostnames (ie: google-verification-randomstring.mydomain.com) that contain a verification string or hostname. This avoids all of the problems above. The name can’t be guessed, and each record is separate. And either the hostname or value should indicate what service the record is for. Having a random value like 25376de5f10046a853b1395e756cbf66 doesn’t help me know what service it belongs to (I’m looking at you AWS Certificate Manager?)

This is the kind of bloat you end up with when everybody uses TXT record, and when people add stuff who don’t know what they are doing.

01:21 $ dig -ttxt mydomain.com

; <<>> DiG 9.18.30-0ubuntu0.20.04.2-Ubuntu <<>> -ttxt mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26429
;; flags: qr rd ra; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;mydomain.com.		IN	TXT

;; ANSWER SECTION:
mydomain.com.	277	IN	TXT	"google-site-verification=qX5fQ3XXXXXXXXXXXXXXXXXXWvxBGAlVigFEW3nYzfU"
mydomain.com.	277	IN	TXT	"google-site-verification=oAHQRYYYYYYYYYYYYYYYYYYYYYD447rpeYhE81wPD44"
mydomain.com.	277	IN	TXT	"slack-domain-verification=sa2uZZZZZZZZZZZZZZZZZZZZZZZZZZZZZtTRsDOOS"
mydomain.com.	277	IN	TXT	"google-site-verification=3LEWAAAAAAAAAAAAAAAAAAAA8GGyhpkv-Ge3qhaOIn8"
mydomain.com.	277	IN	TXT	"facebook-domain-verification=zvyCCCCCCCCCCCCCCCCCCCCCC5lbhn"
mydomain.com.	277	IN	TXT	"v=spf1 include:spf.mandrillapp.com include:_spf.elasticemail.com include:aspmx.pardot.com ~all"
mydomain.com.	277	IN	TXT	"pardot885593=bd2638dff2ffffffffffffffffffffffffffffffffe46fd6c4dbffefa91"
mydomain.com.	277	IN	TXT	"include:servers.mcsv.net ?all"
mydomain.com.	277	IN	TXT	"include:_spf.google.com include:mailgun.org"
mydomain.com.	277	IN	TXT	"mandrill_verify.tIcfQQQQQQQQQQQQQQQQqaQ"
mydomain.com.	277	IN	TXT	"google-site-verification=rjDDDDDDDDDDDDDDDDDDDDDDDDDtzfGMuZKmt74DfQ0"
mydomain.com.	277	IN	TXT	"brevo-code:a0aaaaaaaaaaaaaaaaaaaaaabebed7419"

;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sun Dec 21 01:22:25 UTC 2025
;; MSG SIZE  rcvd: 984

I know they aren't using several of those services, but cleaning them up requires timely validation just to make sure

It has been a few years since I’ve had to migrate data between Google Workspace accounts, but I recently had to do it again. Google has made some improvements! Namely they have a Migration Service now where you can provide a list of user accounts to migrate from old account to new and it will move all of their emails from their inbox between the accounts! I used to have to do that via a 3rd party service or with an IMAP client manually

The migration service looks like it might handle Google Calendar and Contacts as well

It is still a little bit of a hassle to transfer ownership of Google Docs between accounts. Google doesn’t let you change ownership directly from one person in an organization to a person in a different organization. But you can work around that by using Google Shared Drives.

1. Set up a shared drive, and share the drive with both the old and new Google Workspace accounts. Make sure to grant them the full “Manager” permission (Content manager won’t allow transferring ownership)
2. From the old account, move all of the content to the shared drive. I usually do this in a folder within the shared drive if there is stuff already there
3. From the new account, access the same Shard drive and move the content from the shared drive back into your own Drive. This transfer ownership to the individual user

Note that you can’t move items that were shared with you. They will cause an error when its checking what can be moved. Also, after you move a document, the URL for it changes, so any links between documents will likely be broken and will have to be re-linked