(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.
I do use a similar approach to backup the Symantec secret - but what percentage of users do you think are capable of doing this? 0.1%?
> 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.
A phishing attempt will do precisely this. You get a fake login page, type in your creds, and then you get a fake TOTP page.
> 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.
In a prior life I did some research on phishing. It is embarrassingly easy to fool even professional security researchers. Nobody is capable of consistently preventing phishing by using their own eyes and brain.
If you can manage a 100% policy of using no services that ever require users to do X, then you can also just disable doing X entirely through MDM. Phishing emails can't get your users if your users' email clients don't open links other than to whitelisted domains. :)
I've got a few services that only support Symantec VIP, which does not allow you to extract secrets.
> Sufficient paranoia / user training is enough to protect against phishing.
Considering how easily actual factual professional security engineers fall for phishing, I don't believe you.