See https://www.reddit.com/r/1Password/comments/8yey6y/how_do_i_...

(PITA, I know, but running little auth gateways like this is part-and-parcel of doing security for an org.)

> Considering how easily actual factual professional security engineers fall for phishing, I don't believe you.

It's almost always the service's fault for being designed in such a way that its real async user interactions are indistinguishable from phishing. You can't train a user to distinguish X from X.

• It's hard to train users to not forward TOTP tokens sent to them to someone else, if the real service will text or push-notifies the user their TOTP token "at random" (i.e. because the attacker tried to log in.) But if the service never does that — if you always have to go and fetch the token from your TOTP app — then you can just tell the user that the only time they are to go do that, is right after they've typed their username and password as part of logging in themselves; and that anything else is a phishing attempt.

• It's hard to train users to not type their username+password into phishing login pages, if the services you use constantly send you emails containing deep links. But if the service never does that — if the service always tells you to go your browser and navigate to the site yourself — then it's easy to teach users to never trust a login initiated through an email.

Security, in this case, is less about "good security hygiene", and more about priming/expectations. And because of that, the practice of being an IT admin for such an org, is a practice of picking services, or negotiating with services, to ensure that the service is following secure workflows when dealing with your users, so that your users can be trained.