Защо "Не кликай върху съмнителни линкове" вече не е достатъчно

Всяка година тренингите по сигурност ни повтарят едно и също нещо: провери URL адреса, потърси HTTPS, никога не въвеждай паролата си на непознати сайтове. Като цяло съветът е разумен. Но в реалността сме изградили толкова объркани системи за автентикация, че на практика караме потребителите да решават пъзел, чийто отговор се променя всеки сезон.

Неудобната истина е: фишингът не винаги е провал на потребителя. Често това е провал в архитектурата.

Когато легитимните сайтове изглеждат като измами

Спрете се за момент и огледайте собствения си процес за вход. Ако сте като повечето компании, този бутон за вход вероятно препраща потребителите през лабиринт от външни доставчици на идентичност, федерирани услуги за автентикация и крайни точки с токени, които подозрително много приличат на опити за фишинг.

https://app.tвоятакомпания.com → 
https://auth.identityprovider.io/tвоятакомпания →
https://sso.federatedservice.com/session/token →
https://verify.authentication-processor.com/mfa

Нито един от тези URL адреси не е на домейна на твоята компания. Нито един не е запомнящ се. И нито един не дава на потребителите шанс да различат истинското от фалшивото.

Нападателят се нуждае само от три неща, за да възпроизведе това изживяване: убедителен шаблон, откраднато лого и поле за парола. самият URL е станал безсмислен, защото сме обучили потребителите да го игнорират.

Защо URL адресите никога не са били проектирани за това

Да бъдем честни — структурата на URL адресите е объркваща по принцип и не бива да очакваме нетехническите потребители да ги анализират като разработчици.

Разгледайте този URL:

https://login.staging.internal.example-corp.com/auth/verify

Повечето потребители виждат "staging" и "internal" и веднага губят интерес. Търсят името на компанията, и дори когато го намерят, не могат да преценят дали заобикалящата инфраструктура е легитимна или майсторска имитация.

Името на хоста се чете от конкретното към общото (login → staging → internal → example-corp → com), което означава най-важният идентификатор — реалният домейн — е заровен някъде по средата. Потребителите се научават да търсят името на марката навсякъде в URL адреса, а това точно е навикът, който фишърите експлоатират.

Протокол → Субдомейн(и) → Домейн → TLD → Път
    |          |           |       |      |
  HTTPS      login      example   com    /auth

Разработчиците разбират това интуитивно. Обикновените потребители нямат шанс, когато нормализираме URL адреси като:

https://auth.company.suspicious-vendor.io
https://company.auth-vendor.io/sso/abc123
https://auth-vendor.io/company-signin

Отговорността на разработчиците

Ето къде става интересно за теб: ти имаш силата да проектираш автентикационни изживявания, които защитават потребителите по подразбиране.

Вместо да препращаш потребителите през лабиринт от трети страни домейни, помисли върху тези принципи:

1. Притежавай своя identity домейн. Твоят основен бранд домейн трябва да обработва автентикацията. Ако се налага да използваш външни доставчици на идентичност, настоявай за персонализирани субдомейни:

✓ https://login.tвоятакомпания.com
✗ https://auth.vendor.com/tвоятакомпания

2. Съгласувана йерархия на субдомейните. Ако основното ти приложение е на app.компания.com, автентикацията ти трябва да е на auth.компания.com — не заровена три нива надолу под чужда инфраструктура.

3. Пренасочвай интелигентно. Когато се налага да линкнеш към външни услуги (анкети, платежни системи, портали за поддръжка), използвай server-side redirects от твоя собствен домейн. Това дава на потребителите последователно изживяване и затвърждава, че "ако не идва от нашия домейн, не е наше".

4. Отнасяй се към SMS и телефонните номера по същия начин. Съобщенията "обади се на този номер" или "изпрати този код" са точно толкова опасни колкото имейл линковете. Винаги включвай контактна информация към страница, на която потребителите вече имат доверие.

Изграждане на сигурност, която работи ЗАЕДНО с потребителите

RFC 2119 терминологията не е просто бюрократичен жаргон — тя е философия за дизайн. Когато автентикационната сигурност е "SHOULD" вместо "MUST", получаваме ситуацията, в която се намираме днес: див запад от федерирани identity услуги, където легитимните сайтове са неразличими от измамите.

Организациите, които ще спечелят в сферата на сигурността, са тези, които спрат да третират потребителите като най-слабото звено и започнат да изграждат системи, в които сигурният избор е и най-лесният избор.

Защото ето каква е реалността: не можеш да се измъкнеш от проблем в дизайна с тренинги по сигурност.

Какво означава това за твоя стартъп или бизнес

Ако изграждаш или поддържаш автентикационни потоци, сега е моментът за одит. Задай си тези въпроси:

• Може ли нов потребител да идентифицира твоята страница за вход само по URL адреса?
• Всички ли твои автентикационни преживявания преминават през домейни, които потребителите разпознават?
• Използваш ли BYO domain функциите на външни услуги, или приемаш техните default URL адреси?

Това не е просто за сигурност като представяне — става въпрос за изграждане на доверие. Потребители, които се чувстват уверени в твоето автентикационно изживяване, са потребители, които се доверяват на продукта ти.

В NameOcean сме видели как domain стратегията се пресича със сигурността на архитектурата. Твоят домейн не е просто адрес — той е основата на потребителското доверие. Увери се, че твоят работи за теб, а не срещу теб.