Phishing-resistant MFA: FIDO2 / WebAuthn / passkeys

Многофакторна автентикация, при която криптографският authenticator е обвързан с реалния домейн/услуга и не изпраща reusable secret към phishing страница.

Приоритет P0свързана с 21 атаки

Какво е

Многофакторна автентикация, при която криптографският authenticator е обвързан с реалния домейн/услуга и не изпраща reusable secret към phishing страница.

Как работи

FIDO2/WebAuthn използва public-key cryptography. За всяка услуга се създава отделна двойка ключове. Частният ключ остава в authenticator-а/устройството, а услугата пази публичния. Фалшив домейн не може просто да препрати кода, защото удостоверяването е cryptographically bound към правилния verifier/origin.

Примерен сценарий: фалшив Microsoft 365 login

Служител получава линк към страница, която визуално копира Microsoft 365. При традиционна парола + SMS код нападателят може да препрати и двете към истинската услуга. При WebAuthn/passkey браузърът и authenticator-ът участват в проверка, свързана с правилния origin. Фалшивият домейн не получава reusable „код“, който просто да препрати.

Мит срещу реалност

Мит: „Имаме MFA, значи phishing вече не е проблем.“

Реалност: SMS, voice OTP и обикновен push са MFA, но не са равностойни на phishing-resistant authentication. Attackers могат да крадат OTP, да злоупотребяват с push prompts или да използват AiTM proxy, който открадва вече удостоверена session.

Къде прекъсва attack chain-а

Phishing page → credential entry → MFA challenge → session creation

FIDO/WebAuthn е най-силно точно в стъпката authentication. След това все още трябва да пазите endpoint-а, browser session-а и recovery процеса.

Как да проверим, че работи

  • Опитайте вход към корпоративната услуга от lookalike/test домейн: authenticator-ът не трябва да може да валидира грешния origin.
  • Проверете дали администраторите все още имат SMS/voice fallback.
  • Проверете recovery flow-а: ако help desk може да върне account-а само по телефонен разговор, силното MFA е заобиколено от слаб recovery процес.

Практическа имплементация

  • Admin и privileged accounts: FIDO2/security keys задължително.
  • Workforce: passkeys или platform authenticators.
  • Забрана на SMS/voice като primary MFA, когато е възможно.
  • Disable legacy/basic authentication.
  • Recovery flow да изисква силна проверка, не само SMS.
  • Conditional Access за high-risk sign-ins.

Какво НЕ решава

Не спира malware на endpoint-а, session-cookie theft след успешно login, OAuth consent abuse, compromised recovery process или attacker, който вече има валиден refresh token.

Предпазва най-силно от

Помага частично срещу

  • Access-token theft · Пароли, идентичност, MFA и account takeover
    3.17–3.21 Session/token attacks — само частично
  • Device-code phishing · Социално инженерство и phishing
    1.26 Device-code phishing — частично
  • OAuth refresh-token theft · Пароли, идентичност, MFA и account takeover
    3.17–3.21 Session/token attacks — само частично
  • Session fixation · Пароли, идентичност, MFA и account takeover
    3.17–3.21 Session/token attacks — само частично
  • Session hijacking · Пароли, идентичност, MFA и account takeover
    3.17–3.21 Session/token attacks — само частично
  • Session-cookie theft / Pass-the-Cookie · Пароли, идентичност, MFA и account takeover
    3.17–3.21 Session/token attacks — само частично

Кой го търси

4 отворени обяви искат това умение. Затворените обяви не се броят — това е търсенето сега.

Всички обяви по киберсигурност

Други в Идентичност, автентикация и достъп

Number matching и context-aware MFAConditional Access / risk-based accessPrivileged Access Management (PAM) и Just-in-Time (JIT)Least privilege и RBAC/ABACPassword manager + unique passwordsAccount lifecycle management