What to make of inconsistent TFA/2FA verification emails from AOL

Question

My parents use AOL (there's no point trying to migrate them at this stage) with two factor authentication. My father let me know that he recently received an identity log in verification email that looks suspicious.

The resolved client location in the email my dad received is marked as Brazil, which would imply to me his password's compromised by someone routing through Brazil and we should rotate his password and review his security.

However, the verification email itself is a bit suspicious to me. Maybe I'm being paranoid, but I resurrected my old AOL account, which also has TFA, so that I could trigger a verification email to compare it. There are some odd variations I circled in red.

In the suspect email (left) there is no "name" in the salutation (maybe just bad email templating), and the verification code is 8 characters long. In my trusted verification email (right) the verification code is 4 characters. Also, my name appears in the salutation (though purposefully obfuscated).

Although I'm sure AOL could be using variable length codes, their challenge form specifies 4 characters even when I used a couple different browsers/devices. Maybe our accounts are flagged for different verification code lengths somehow, but I keep consistently getting 4 characters. I tried and failed to find any literature on pros/cons of variable verification code length or any official word on what length AOL uses.

The safe route seems to be to rotate his password and move on. However...

Is there anything possibly nefarious about the "suspicious" verification email?

The sender information, links, and overall formatting seem to imply the email is in fact legitimate. It's just weird to notice those irregularities.

Answer 1

Per Filipe dos Santos' note in the comments I reached out to AOL support. It took some prodding, but it sounds like 4/8/variable length TFA codes are possible, "For more security"

The missing salutation is odd, but probably more to do with poor formatting.

I'd say in this particular case there's nothing nefarious/suspect. This experience reinforces for me that consistent behavior and user messaging helps encourage trustworthiness.

Answer 2

There are two telltale signs I'd seek in this sort of message.

First is the links. Never click any of them. If a link doesn't go to the obvious destination, in this case something whose host is aol.com or ends in .aol.com (or another recognizable and appropriate Verizon-owned domain), be very suspicious. If that link is the one they want you to click on, it's a phishing attack for sure (or the team that composed that message is inept; Verizon shouldn't have this problem).

Just as when you're verifying somebody's authenticity over the phone (ask for how to be directed to a verifying source at a phone line but independently find the phone number), you need to go to the login page through a more trustworthy channel, like a bookmark or manually entering aol.com in your browser (not as a Google search). There shouldn't be much harm in entering a fake MFA challenge into the real site.

Second is to check the anti-spoofing measures used by the message. This is more tedious and requires more technical chops. Open up the message's full header view and seek out the Received headers. This should be sent directly from AOL to you. If it comes from anywhere else, you'll have to look up to see if they're a security partner (this is complicated). One shortcut you can take is to use a tool like Google Admin Toolbox Messageheader and paste your headers in there. It'll tell you what each relay means and give you a much more human-friendly view to review (iirc, they assume you're using Google infrastructure, so ignore those warnings if you're not using Google).

If it passes DMARC (though I don't recall if this tool checks DMARC), you can be sure the message comes from the domain used in the From header address.

Otherwise, you should check DKIM or SPF and then manually verify its alignment (a DMARC term).

If it passes DKIM, check that the DKIM-Signature header includes a d=DOMAIN where DOMAIN is has the same public suffix (paid-level domain) as the From header address's domain (e.g. security.aol.com is the same as aol.com but foo.co.uk is not the same as co.uk; see the Public Suffix List).

If it only passes SPF, that's slightly more tedious since you'll have to verify that the SMTP mail from command has the same public suffix as the From header, which isn't obvious.