How does apple mail deal with 2FA

I recently set up 2fa on some emails and chose google authenticator as the second method. These providers are outlook and gmail.

When I use thunderbird on linux mint, I need to generate an app password to log in. Sometimes these passwords seem to expire but this is not my question, only a ”proof” that 2fa really is turned on, and that google auth isn’t only an optional sign-in method.

Mail on iphone (SE 2020, os 14.6) always works at first setup, never failing, despite only knowing my login password (both two providers). What is going on here? Am I dealing with a feature or a vulnerability?

Here is what I’ve considered but failed to query here or on google. A) the smart phone connects to the server very often, therefore the app password does not expire

B) the smart phone always looks up one-time passwords on google authenticator, performing repeated logins that I do not see

C) the smart phone is a ”trusted device” that can somehow ignore 2fa

If this is a vulnerability, I would like to know if it is serious. If it is a feature, are there methods to implement it on other devices (e.g. ubuntu pc)

Edit: I’m really asking why does mail (software) even work. Removed a reference to icloud as irrelevant.

Solution 1:

I asked the wrong question based on a mistaken assumption. That assumption was that Apple was somehow escalating privileged access. instead my problem was provider - 3rd party client problems, for example Microsoft kept disbanding app passwords by some unknown metrics. Google just labeled some of them unreliable, see:Geary.

I had mistakenly assumed 2fa to mean login pass and authentication always. That just isn’t so - in fact I knew about ”trusted devices”, the confusion came from this tiny detail; my iphone wan’t listed as such a device, it could presumably be removed by ”revoke all” but I need mine operational 24/7 and daren’t risk it now. Based on comments, my hypothesis is that, if certain clients aren’t even trusted to handle the very basics, perhaps apple mail - on ios - on an iphone, was given a special token, a token with no set final date, always on, unless revoked. Oh and I did check that authenticator weren’t even required, on this phone. The answer according to my options is C, this is a trusted device. As for the token, I don’t know exactly. Input from apple server modified by some unique process to send the resulting output as proof of identity? But now I’ll know what I’m looking for, it is not authenticator nor a manual prompt. I suggested that the prompt was only needed once, but something similar might just be running under the hood.

I mistakenly identified iphone as single point of failure, to be equal to untrustworthy. And yes, it could establish a vulnerability in some cases, but I made a gross exaggerarion. So let’s compare it to a pc computer: 1) encryption as default vs optional, 2) optional login pass 3) biometrics. The phone has similar or better options and phones often have other architecture security benefits. Both devices use authenticators and password managers too. I can’t recall giving my iphone a special status, but I must have done so. After all it was a matter of 1) device pass login 2) google pass login 3) terms and confirmation 4) google prompt to confirm.

Two passwords and a 2nd factors, pretty good identification to me

Potential issue: ease-of-use can be misread as lax sexurity, disfunctional logins can be misread as strong security. Or wait was that just me? Can’t be just me

Summa summarum: my concept of 2fa was very rigid, I even misattributed flawed auth scenes to stricter security,

p.s I posted a horrible blog entry here that was illegible and incoherent. I’m struggling with record heat. Having regained some composure I’ll stop here and thank you for pointing the righr way.

Solution 2:

Both Mac and iOS Mail applications will bring up the Google login page for Gmail connections. Google processes the 2 Factor Auth and the Mail app doesn't need to worry about it. Gmail provides the Mail application with a token that it can use indefinitely.

Other applications that ask for your username and password in their own UI need an app-specific password since they don't get to take advantage of the Google-provided login flow.