> You should obviate the need for employees to even use passwords in a corporate context, and you should use authentication systems which aren't phishable.
What are best practices or products for this?
What are best practices or products for this?
2. Access control policies which minimize privileges to only those which are needed.
3. Put everything behind corporate SSO instead of per-account passwords and login pages.
4. An authenticating proxy that enforces policies on each individual machine using something like webauthn.
The first recommendation limits the extent to which accounts can be compromised if users mistakenly enter their passwords. The second limits the damage which can be done when accounts are compromised. The third limits the general attack surface of passwords entirely, as does the fourth. In particular: the fourth also allows you to remove your corporate VPN while leveraging SSO. It also makes it easier to enforce the granular access control policies.
These things can be a heavy upfront technical investment, but there are off the shelf solutions and products for each of them. They're also easier than trying to train humans to be superhuman.
A key touch on fakegoogle.com can’t be proxied to authenticate on google.com
So, that verification step takes places inside your web browser. In this specific context this means a vulnerability is that your employees might install software which is also able to perform the same steps but unlike say, Chrome, does not do DNS name checks, perhaps it even intentionally always tries to generate authentications for google.com.
On a very locked down platform, such as an iPhone, or some employee laptops in corporations where employees aren't trusted to install software, there should be no way for that software to run. On Android, Google get to bless binaries with the privilege to do this, they bless the built-in Android browser, Chrome, production builds of Firefox, and I suppose it's likely there are similarly popular browsers I haven't heard of, but there is no way for a normal out-of-box Android device to just install some garbage adware that does WebAuthn even with a manual APK install. If you lack that privilege, when you ask Android to talk to a Security Key it fills out the parameter where a DNS name would go with a per-app ID. So you can use Security Keys to do cool stuff from an app, but you can't fake WebAuthn.
e.g. you can work out the ID assigned to your app, get the backend code your server people wrote for WebAuthn, and spin up another copy that checks that ID instead of your DNS name, now you've got a one touch in-app sign-in that works with fingerprint sensors on popular phones the same way WebAuthn does for your web site.
The user presence detection means that even if the DNS name matching mechanism is defeated (e.g. you have software install privileges because you work in the IT division, you install software from a phishing mail) the user needs to actually touch the sensor/ press the button/ whatever to signify presence, which requires further social engineering each time. In a spear phishing attack this is definitely conceivable but it's one last opportunity for your victim to say, hang on, what's going on here?
User Presence is a signed bitflag (it's also mandatory on most of the cheap devices anyway) which means it can't be faked even on the cheapest possible CTAP2 implementation, and a WebAuthn server implementation can have confidence in the value of that bitflag when received, the WebAuthn spec. says the implementations should reject authentications where that bitflag is not set.