2 ms·

That’s great if you can do it, unfortunately companies with big slow IT departments that don’t like making changes they didn’t ask for tend to see “MFA on all r

That’s great if you can do it, unfortunately companies with big slow IT departments that don’t like making changes they didn’t ask for tend to see “MFA on all remote services” as a multi year project and widespread use of hardware tokens as impossible. For companies in that situation using something like the HIBP domain notifications can be helpful. When MFA is in place you still have to keep loopholes in mind, things I’ve seen recently at various companies include a user blindly approving Duo prompts and letting an attacker on to the VPN, a Fortinet appliance that was supposed to be decommissioned a year ago that wasn’t, allowing an attacker to log in with credentials stolen previously, and legacy HTTP basic auth in Office 365, which bypasses MFA unless it’s disabled.

tialaramex 6y ago
> include a user blindly approving Duo prompts Sure, one of the reasons I specified WebAuthn is that intuitive security properties tie up better. Users have seen keys before, if I give Bob this Security Key, obviously Bob can unlock the same things as I could with the Security Key. Whereas a lot of these other technologies are a bit abstract - I should fill this six digit code into this web site but not any other web site? The phone might give me a Duo prompt out of the blue but I shouldn't say yes? Actually WebAuthn's Security Keys have behaviour that matches people's intuitive understanding of actual keys somewhat better than the actual keys do. If I examine the lock I can make a key for it! If I see one key, I can use that to make more keys that all work! These are properties of real mechanical keys that surprise users but aren't present in WebAuthn's Security Keys.