Autenticação por SMS para WiFi: Como Funciona e Quando Usar

Autenticação por SMS para WiFi: Como Funciona e Quando Usá-la Um Briefing de Inteligência da Purple Enterprise WiFi [SEGMENTO 1 — INTRODUÇÃO E CONTEXTO — aprox. 1 minuto] Bem-vindo ao Briefing de Inteligência da Purple WiFi. Sou o seu anfitrião e hoje vamos directos a uma das decisões mais práticas que irá enfrentar ao implementar WiFi para convidados em grande escala: deve autenticar os seus utilizadores através de um código de acesso único por SMS ou deve optar pelo login social, verificação por e-mail ou algo completamente diferente? Esta não é uma discussão teórica. Quer esteja a gerir um hotel com 400 quartos, um centro comercial regional, um estádio da Premier League ou uma rede de bibliotecas públicas, o método de autenticação que escolher tem implicações directas na sua conformidade, na qualidade dos seus dados, na experiência do convidado e, em última análise, no valor comercial que extrai do seu investimento em WiFi. Nos próximos dez minutos, vou explicar-lhe exactamente como funciona a autenticação WiFi por SMS nos bastidores, que dados capta e por que razão isso importa, e os cenários específicos em que supera as alternativas. No final, terá uma estrutura de decisão clara que poderá apresentar à sua equipa ainda esta semana. Vamos a isso. [SEGMENTO 2 — ANÁLISE TÉCNICA DETALHADA — aprox. 5 minutos] Então, vamos começar pelo essencial. O que acontece realmente quando um convidado se liga à sua rede WiFi e passa por um fluxo de OTP por SMS? O processo começa no momento em que um dispositivo se associa ao seu SSID. Na camada de rede, o seu controlador de acesso — quer seja uma plataforma gerida na nuvem como a Purple, ou um controlador de hardware de um fornecedor como a Cisco Meraki ou Aruba — intercepta todo o tráfego HTTP de saída desse dispositivo. Faz isto antes de o dispositivo ter acesso total à internet. O mecanismo é um Captive Portal, e o redireccionamento é tipicamente uma resposta HTTP 302 padrão que empurra o browser do dispositivo para a sua página de entrada personalizada. Agora, é aqui que a autenticação por SMS se afasta de outros métodos. Em vez de pedir ao convidado para iniciar sessão com uma conta social ou introduzir um endereço de e-mail, o portal apresenta um único campo de introdução: um número de telemóvel, com um selector de código de indicativo internacional. O convidado introduz o seu número e clica em submeter. Nesse ponto, a sua plataforma de WiFi faz uma chamada de API para um fornecedor de gateway de SMS — Twilio, MessageBird, Vonage ou semelhante — transmitindo o número de telefone e solicitando que um código de acesso único seja gerado e enviado. O OTP é normalmente um código numérico de seis dígitos com um tempo de vida útil de três a dez minutos, dependendo da sua configuração. O código é gerado através de um gerador de números pseudo-aleatórios criptograficamente seguro e é de utilização única. É armazenado no lado do servidor, em formato hash, e comparado com a submissão do convidado. O visitante recebe o SMS no seu telemóvel — normalmente entre dois a cinco segundos numa boa rede móvel — introduz o código no portal e a plataforma valida-o. Após uma validação bem-sucedida, o controlador de acesso abre uma regra de política que permite ao endereço MAC desse dispositivo encaminhar tráfego para a internet. A sessão é registada com um carimbo de data/hora, o número de telefone verificado, o endereço MAC do dispositivo, o identificador do ponto de acesso e a localização do espaço. Do ponto de vista das normas, este fluxo enquadra-se na arquitetura mais ampla de Captive Portal definida na RFC 7710 e na especificação da Captive Portal API do IETF. A segurança do WiFi subjacente é totalmente independente — normalmente executa WPA2 ou WPA3 no SSID, e o Captive Portal opera na Camada 7, não na Camada 2. Vale a pena clarificar esta distinção: o OTP por SMS é um mecanismo de verificação de identidade, não um mecanismo de encriptação de rede. Os dois funcionam em paralelo. Agora, que dados são efetivamente capturados por este processo e por que motivo é que isso importa? O principal ponto de dados é um número de telemóvel verificado e ativo. Quero enfatizar a palavra "verificado", pois este é o principal fator de diferenciação face à autenticação por e-mail. Um endereço de e-mail pode ser uma conta descartável criada em trinta segundos. Um número de telemóvel associado a um cartão SIM ativo é uma âncora de identidade persistente e do mundo real. É significativamente mais difícil de fabricar à escala e é diretamente acionável para comunicações de acompanhamento através de marketing por SMS — sujeito, obviamente, ao consentimento explícito do visitante, que o seu portal deve capturar no momento do início de sessão. Além do próprio número de telefone, uma implementação de autenticação por SMS bem configurada captura: o carimbo de data/hora da primeira ligação e de cada ligação subsequente; o ponto de acesso ao qual o dispositivo se ligou, o que lhe fornece dados de localização física dentro do seu espaço; o endereço MAC do dispositivo, que permite a identificação de visitantes recorrentes; a duração da sessão; e, se estiver a executar uma implementação em múltiplos locais, o espaço ou propriedade específica. Este conjunto de dados é reduzido por conceção. Comparado com o início de sessão social, que pode extrair nome, e-mail, foto de perfil, gráfico de amigos e dados comportamentais de uma plataforma de terceiros, a autenticação por SMS captura o conjunto mínimo de dados de identidade viável. E num ambiente regulatório pós-GDPR, essa redução é uma vantagem, não uma limitação. Deixe-me falar sobre a vertente da conformidade com um pouco mais de detalhe, porque é aqui que vejo a maior confusão no terreno. Ao abrigo do GDPR do Reino Unido e do seu equivalente na UE, necessita de uma base jurídica para processar dados pessoais. Para o WiFi de visitantes, a base mais defensável é tipicamente o interesse legítimo ou, para fins de marketing, o consentimento explícito. A autenticação por SMS suporta ambos de forma clara. O número de telefone é recolhido com um propósito claro — o acesso à rede — e qualquer consentimento de marketing é capturado como uma caixa de seleção separada e desvinculada no momento do registo. Não existe ambiguidade sobre os dados que possui, a sua origem ou para que finalidade são utilizados. O login social, por outro lado, introduz um controlador de dados terceiro na sua cadeia de consentimento. Quando um convidado inicia sessão com a sua conta do Facebook, está a depender da implementação OAuth da Meta, das práticas de dados da Meta e da compreensão do convidado sobre o que está a consentir. Do ponto de vista de um Encarregado de Proteção de Dados (DPO), essa é uma superfície de responsabilidade mais complexa. Vários grandes grupos hoteleiros com quem trabalhei abandonaram o login social especificamente porque os seus DPOs sinalizaram a complexidade da cadeia de consentimento como um risco inaceitável. Existe também um argumento prático de resiliência a favor da autenticação por SMS. O login social exige que o seu portal faça chamadas de API externas para os endpoints de OAuth da Google, Facebook ou Apple. Se esses serviços sofrerem tempo de inatividade — o que acontece — todo o seu fluxo de integração de convidados falha. Os fornecedores de gateway de SMS, em contrapartida, oferecem SLAs de disponibilidade extremamente elevados, normalmente de 99,95% ou superior, e pode configurar o failover entre múltiplos fornecedores. Para um estádio que acolhe um evento num dia de jogo com 60.000 dispositivos simultâneos, essa resiliência é incrivelmente importante. [SEGMENTO 3 — RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS — aprox. 2 minutos] Muito bem, falemos sobre a implementação. Como é que se parece, na verdade, uma implementação de autenticação por SMS bem executada? Primeiro, a seleção do gateway. Não utilize por predefinição um único fornecedor de SMS. Configure a sua plataforma para suportar pelo menos dois fornecedores de gateway com failover automático. Encaminhe números internacionais para fornecedores com forte cobertura regional — um fornecedor sediado no Reino Unido pode ter excelentes taxas de entrega a nível nacional, mas um rendimento fraco para redes móveis do Sudeste Asiático. Se gere uma marca de hotéis internacional, isto é importante. Segundo, expiração de OTP e limitação de taxa (rate limiting). Defina o tempo de vida do seu OTP para cinco minutos — tempo suficiente para um convidado que está a mexer no telemóvel, curto o suficiente para limitar a janela de ataques de preenchimento de credenciais (credential stuffing). Implemente a limitação de taxa ao nível do número de telefone: não mais do que três pedidos de OTP por número por hora. Isto evita que o seu orçamento de SMS seja consumido por abusos automatizados e protege contra ataques de enumeração baseados em SIM. Terceiro, gestão de sessões. Defina cuidadosamente as suas políticas de expiração de sessão. Para um hotel, uma sessão de 24 horas com reautenticação automática ao regressar é apropriada — os convidados não querem voltar a verificar-se sempre que regressam do pequeno-almoço. Para um estádio ou recinto de eventos, sessões mais curtas, de duas a quatro horas, alinhadas com a duração do evento, são mais adequadas e proporcionam-lhe uma segmentação de dados mais limpa por evento. Quarto, a recolha de consentimento. Isto é inegociável. O seu portal deve apresentar uma caixa de seleção de consentimento de marketing clara e desvinculada — separada da aceitação dos termos de serviço — antes de o convidado submeter o seu número de telefone. Caixas pré-selecionadas não estão em conformidade com o GDPR. O registo de consentimento, incluindo a marca temporal e a redação exata mostrada ao convidado, deve ser armazenado e poder ser recuperado para fins de auditoria. Agora, os problemas. A falha mais comum que vejo é a fraca cobertura móvel dentro do espaço. Se os seus visitantes estiverem numa sala de reuniões na cave ou num corredor de hotel com paredes espessas e sem sinal móvel, não conseguirão receber o SMS. A mitigação passa por oferecer uma via alternativa de autenticação — OTP por e-mail ou um simples clique de acesso — como alternativa, claramente assinalada no portal. Não faça do SMS a única opção. O segundo problema é a formatação de números internacionais. Se o seu portal não processar corretamente o formato internacional completo E.164 — ou seja, o sinal de mais, o código do país e o número de assinante —, falhará silenciosamente no envio de OTPs para visitantes internacionais. Teste o seu portal com números de, pelo menos, cinco códigos de país diferentes antes do lançamento. [SEGMENT 4 — RAPID-FIRE Q&A — approx. 1 minute] Deixe-me abordar rapidamente algumas perguntas que oiço regularmente de arquitetos de rede e gestores de TI. "A autenticação por SMS pode funcionar em conjunto com o 802.1X para redes de colaboradores?" Sem dúvida. Executa SSIDs separados — 802.1X com autenticação baseada em certificados para colaboradores, Captive Portal com SMS OTP para visitantes. Operam de forma independente na mesma infraestrutura física. "A autenticação por SMS funciona em dispositivos iOS com randomização de endereço MAC?" Sim. A randomização de MAC afeta a monitorização do dispositivo entre sessões, mas numa única sessão o MAC é estável. Para identificação de visitantes frequentes, faz-se a correlação através do número de telefone verificado, não pelo endereço MAC. A plataforma da Purple lida com isto de forma nativa. "Qual é o custo típico de SMS por autenticação?" À escala, estamos a falar de um a três cêntimos por OTP entregue no Reino Unido, ligeiramente superior para números internacionais. Para um hotel de 200 quartos que realize 150 novas autenticações por dia, isso representa cerca de £1.500 a £2.500 por ano em custos de gateway — uma linha de custos negligenciável face ao valor de dados e marketing gerado. "A autenticação por SMS é adequada para ambientes PCI DSS?" O SMS OTP não é um controlo de autenticação PCI DSS para ambientes de dados de titulares de cartões. É um mecanismo de identidade de visitantes para acesso à rede. Mantenha a VLAN do seu WiFi de visitantes estritamente segregada de qualquer infraestrutura de rede de pagamentos, e não terá problemas com o âmbito do PCI. [SEGMENT 5 — SUMMARY & NEXT STEPS — approx. 1 minute] Para resumir as principais conclusões do briefing de hoje. A autenticação de WiFi por SMS fornece uma âncora de identidade verificada e persistente — o número de telemóvel — com um impacto mínimo de recolha de dados e um perfil de conformidade simplificado com o GDPR. É a escolha certa para hotelaria, eventos e implementações no setor público onde a demografia dos visitantes é ampla, a posse de contas de redes sociais não pode ser assumida e a simplicidade de conformidade é uma prioridade. O fluxo técnico é simples: redirecionamento do Captive Portal, inserção do número de telefone, envio do SMS OTP via API de gateway, validação do código, abertura de sessão. Os dados recolhidos são reduzidos mas acionáveis: número verificado, carimbo de data/hora, localização, identificador de dispositivo. Escolha o SMS em vez do login social quando o seu público for demograficamente diversificado, quando o seu DPO tiver preocupações sobre cadeias de consentimento OAuth de terceiros ou quando precisar de resiliência contra falhas de plataformas de terceiros. Os seus próximos passos imediatos: audite o seu método de autenticação atual em relação aos seus requisitos de conformidade. Se utiliza o login social e não reviu a sua cadeia de consentimento recentemente, essa é uma conversa a ter com o seu DPO este mês. Se está a implementar um novo espaço, configure o OTP por SMS como o seu método principal com o email como alternativa, e configure fornecedores duplos de gateway de SMS desde o primeiro dia. Para saber mais sobre a plataforma de inteligência de guest WiFi da Purple e como a autenticação por SMS se integra com a nossa suite de analítica e automação de marketing, visite purple.ai. Obrigado por ouvir.