Não Culpe o Usuário Pelo Phishing: O Problema Está na Sua Autenticação

O Discurso do "Não Clique em Links Suspeitos"

Todo ano, os treinamentos de segurança repetem a mesma ladainha: verifique a URL, procure o HTTPS, nunca digite sua senha em sites desconhecidos. Na teoria, parece sólido. Na prática, construímos sistemas de autenticação tão复杂度 (complexos) que básicamente pedimos para o usuário resolver um quebra-cabeça onde a resposta correta muda a cada trimestre.

Aqui está a verdade incômoda: phishing nem sempre é falha do usuário. Frequentemente, é falha de arquitetura.

Quando Sites Legítimos Parecem Golpes

Pare um momento e examine o fluxo de login da sua própria empresa. Se você é como a maioria, aquele botão de login provavelmente redireciona o usuário por um labirinto de provedores de identidade terceirizados, serviços de autenticação federada e endpoints tokenizados que são assustadoramente similares a tentativas reais de phishing.

https://app.suaempresa.com → 
https://auth.provedordeidentidade.io/suaempresa →
https://sso.servicofederado.com/sessao/token →
https://verificar.processadordeautenticacao.com/mfa

Nenhuma dessas URLs está no domínio da sua empresa. Nenhuma é memorável. Nenhuma dá ao usuário a menor chance de distinguir o real do falso.

Um atacante precisa de apenas três coisas para replicar essa experiência: um template convincente, um logo roubado e um campo de senha. A própria URL se tornou irrelevante porque treinamos os usuários a ignorá-la.

Por Que URLs Nunca Foram Projetadas Para Isso

Vamos ser honestos — a estrutura de URLs é inherently confusa, e não deveríamos esperar que usuários não-técnicos conseguissem interpretá-la como desenvolvedores.

Observe esta URL:

https://login.staging.interno.empresa-exemplo.com/auth/verificar

A maioria dos usuários vê "staging" e "interno" e seus olhos já perdem o interesse. Eles estão procurando o nome da empresa, e mesmo quando encontram, não conseguem dizer se a infraestrutura ao redor é legítima ou uma imitação inteligente.

O hostname lê-se do específico para o geral (login → staging → interno → empresa-exemplo → com), o que significa que o identificador mais importante — o domínio real — fica enterrado no meio. Os usuários aprendem a procurar um nome de marca em qualquer lugar da URL, e esse é exatamente o hábito que phishers exploram.

Protocolo → Subdomínio(s) → Domínio → TLD → Caminho
    |          |           |       |      |
 HTTPS      login      empresa   com    /auth

Desenvolvedores entendem isso intuitivamente. Usuários comuns não têm chance quando normalizamos URLs como:

https://auth.empresa.fornecedor-suspeito.io
https://empresa.fornecedor-de-autenticacao.io/sso/abc123
https://fornecedor-de-autenticacao.io/empresa-login

A Responsabilidade do Desenvolvedor

Aqui está onde isso se torna relevante para você: você tem o poder de projetar experiências de autenticação que protegem usuários por padrão.

Em vez de redirecionar usuários por um labirinto de domínios terceiros, considere estes princípios:

1. Seja dono do seu domínio de identidade. Seu domínio principal deve cuidar da autenticação. Se você precisa usar provedores de identidade terceiros, imponha o uso de subdomínios personalizados:

✓ https://login.suaempresa.com
✗ https://auth.fornecedor.com/suaempresa

2. Hierarquia consistente de subdomínios. Se seu app principal está em app.empresa.com, sua autenticação deve estar em auth.empresa.com — não enterrada três níveis abaixo da infraestrutura de outra pessoa.

3. Redirecione de forma inteligente. Quando precisar linkar para serviços externos (pesquisas, processadores de pagamento, portais de suporte), use redirects server-side do seu próprio domínio. Isso dá aos usuários uma experiência consistente e reforça que "se não vem do nosso domínio, não é nosso."

4. Trate SMS e números de telefone da mesma forma. Mensagens de "ligue para este número" ou "envie um código" são tão perigosas quanto links de email. Sempre inclua informações de contato em uma página que seus usuários já confiam.

Construindo Segurança que Escala Com os Usuários, Não Contra Eles

A terminologia RFC 2119 não é apenas jargão burocrático — é uma filosofia de design. Quando a segurança de autenticação é um "DEVERIA" ao invés de um "DEVE," você chega à situação que temos hoje: um faroeste de serviços de identidade federada onde sites legítimos são indistinguíveis de golpes.

As organizações que vão vencer em segurança são aquelas que param de tratar usuários como o elo mais fraco e começam a construir sistemas que tornam a escolha segura a escolha fácil.

Porque aqui está a realidade: você não pode treinar segurança para sair de um problema de design.

O Que Isso Significa Para Sua Startup ou Empresa

Se você está construindo ou mantendo fluxos de autenticação, agora é a hora de fazer uma auditoria. Pergunte-se:

• Um usuário de primeira viagem consegue identificar sua página de login apenas pela URL?
• Todas as suas experiências autenticadas passam por domínios que seus usuários reconhecem?
• Você está usando recursos de BYO domain de serviços terceiros, ou aceitando as URLs padrão deles?

Isso não é apenas sobre segurança de fachada — é sobre construir confiança. Usuários que se sentem confiantes na sua experiência de autenticação são usuários que confiam no seu produto.

Na NameOcean, vimos como a estratégia de domínio se intersecta com a arquitetura de segurança. Seu domínio não é apenas um endereço — é a foundation da confiança do usuário. Make sure yours is working for you, not against you.