EAP-TLS vs. PEAP: Qual é o Protocolo de Autenticação Adequado para a Sua Rede?

Escolha EAP-TLS quando tem o controlo dos dispositivos. Cada dispositivo prova a sua identidade através de um certificado, pelo que não existem palavras-passe para sofrerem phishing ou serem quebradas. Escolha PEAP quando não puder emitir certificados, como em dispositivos pessoais, e imponha a validação do certificado do servidor em cada cliente. Nenhum dos dois se adequa a convidados anónimos, por isso utilize um captive portal ou OpenRoaming em alternativa.

Deve escolher EAP-TLS ou PEAP?

Ambos os protocolos são executados dentro do IEEE 802.1X, o padrão para controlo de acesso à rede baseado em portas. O 802.1X faz com que um dispositivo prove quem é antes de o ponto de acesso encaminhar o seu tráfego. Essa prova viaja como mensagens EAP (Extensible Authentication Protocol) para um servidor RADIUS, o serviço que aprova ou rejeita cada ligação.

O EAP-TLS e o PEAP são duas formas de transportar essa prova. A diferença reside no que o dispositivo apresenta.

• EAP-TLS está definido no RFC 5216 e foi atualizado para TLS 1.3 no RFC 9190. O servidor e o dispositivo apresentam, cada um, um certificado digital. A identidade assenta numa chave privada que nunca sai do dispositivo.
• PEAP (Protected EAP) solicita um certificado apenas ao servidor. O dispositivo cria um túnel encriptado para o servidor e, em seguida, envia um nome de utilizador e uma palavra-passe no seu interior, quase sempre com MSCHAPv2.

A recomendação resumida:

• Portáteis geridos, tablets, scanners e dispositivos de pagamento: EAP-TLS.
• Telemóveis pessoais e dispositivos de prestadores de serviços que não pode registar: PEAP, com a validação do certificado do servidor ativada obrigatoriamente.
• Convidados, fãs, passageiros e clientes de retalho: nenhum dos dois. Utilize um captive portal ou OpenRoaming através do Guest WiFi.

A maioria das infraestruturas executa ambos os métodos num único serviço RADIUS, separados pela propriedade do dispositivo. O restante deste guia mostra onde se situa essa linha de separação e quanto custa gerir cada opção.

Como diferem o EAP-TLS e o PEAP na prática?

Como funciona o handshake do EAP-TLS

O servidor RADIUS envia primeiro o seu certificado. O dispositivo verifica-o em comparação com uma autoridade de certificação (CA) de raiz fidedigna. O dispositivo envia depois o seu próprio certificado e prova que possui a chave privada correspondente.

O servidor confirma que o certificado do dispositivo é válido e não foi revogado. Verifica a revogação através de uma lista de revogação de certificados (CRL) ou OCSP (Online Certificate Status Protocol, RFC 6960). Só depois é que o ponto de acesso admite o dispositivo.

Nenhuma palavra-passe atravessa a rede em momento algum. Uma palavra-passe obtida por phishing não consegue abrir a rede, porque a rede nunca pede nenhuma.

Como funciona o handshake do PEAP

O servidor RADIUS envia o seu certificado e o dispositivo valida-o. Os dois lados criam um túnel TLS. Dentro desse túnel, o dispositivo executa o MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol versão 2) contra um diretório como o Active Directory. Se as credenciais coincidirem, o dispositivo obtém acesso.

A Microsoft, a Cisco e a RSA Security desenvolveram o PEAP em conjunto. Nunca se tornou um padrão IETF. A Microsoft publica a versão que a maioria dos dispositivos utiliza na sua especificação de protocolo MS-PEAP.

Por que razão a validação do certificado do servidor determina a segurança do PEAP

O túnel protege a palavra-passe apenas se o dispositivo verificar quem está na outra extremidade. Se ignorar essa verificação, um atacante pode transmitir o nome da sua rede a partir de um ponto de acesso rogue, conhecido como "evil twin". O dispositivo conclui então o MSCHAPv2 com o atacante e entrega um desafio e uma resposta.

Em 2012, o Aviso de Segurança Microsoft 2743314 alertou que as trocas MSCHAPv2 não encapsuladas podem ser descodificadas. A mitigação da Microsoft foi envolvê-las em PEAP com validação de certificado de servidor obrigatória. Essa continua a ser a regra hoje.

O EAP-TLS não partilha esta fragilidade. Um dispositivo que alcance um ponto de acesso rogue não tem qualquer palavra-passe reutilizável para entregar.

EAP-TLS vs PEAP lado a lado

Duas alterações de plataforma que mudam a decisão

Windows. A documentação do Microsoft Credential Guard indica que as ligações WiFi e VPN baseadas em MSCHAPv2 não podem utilizar credenciais guardadas quando o Credential Guard está ativo. O Credential Guard está ativado por predefinição em dispositivos Windows 11 Enterprise e Education elegíveis a partir da versão 22H2. A Microsoft recomenda a transição para métodos baseados em certificados, como o EAP-TLS.

Android. As versões recentes do Android removeram a opção de ignorar a validação do certificado do servidor. Os perfis PEAP têm agora de indicar um certificado CA e um domínio de servidor. Isto elimina a lacuna do evil twin, mas torna a configuração manual mais difícil para as equipas.

Quando é que o EAP-TLS é a escolha certa?

Escolha o EAP-TLS quando se verificarem três condições: os dispositivos são da sua propriedade, consegue enviar configurações para eles e uma palavra-passe comprometida causaria danos reais.

• Portáteis da empresa geridos através de uma plataforma MDM (gestão de dispositivos móveis), como o Microsoft Intune.
• Terminais de ponto de venda e leitores portáteis em redes no âmbito do PCI-DSS.
• Comprimidos e carrinhos clínicos em Healthcare, onde uma palavra-passe de enfermaria partilhada é um risco permanente.
• Dispositivos de back-office, receção e governança em hotéis.
• Redes criadas para o modo WPA3-Enterprise 192-bit, que a especificação WPA3 associa aos conjuntos de cifragens EAP-TLS.

Os certificados também tornam o descredenciamento preciso. Cancele um certificado e apenas um dispositivo perde o acesso, enquanto os outros dispositivos da pessoa continuam a funcionar. Isto alinha-se perfeitamente com os processos de entrada, mobilidade e saída no seu MDM e diretório.

Armazene chaves privadas como não exportáveis, no TPM (Trusted Platform Module) ou enclave seguro do dispositivo, onde o hardware o suporte. Um certificado que não pode ser copiado para fora do dispositivo não pode ser reutilizado noutro local.

Cenário prático: um grupo hoteleiro de 30 propriedades

Os cenários neste guia são combinações de implementações comuns, e não resultados de clientes específicos.

Situação. Um grupo hoteleiro gere 30 propriedades com cerca de 200 quartos cada. Portáteis administrativos, tablets do serviço de quartos e PCs da receção partilham uma única rede WiFi de funcionários. Os dispositivos iniciam sessão com PEAP utilizando um punhado de contas do Active Directory partilhadas. Quando um tablet desaparece, a equipa de TI repõe a palavra-passe partilhada e reconfigura todos os dispositivos que a utilizam.

O que foi feito. Todos os dispositivos já estavam inscritos num MDM. A equipa implementou uma PKI na nuvem (infraestrutura de chave pública, o sistema que emite e revoga certificados). A equipa distribuiu certificados de dispositivo utilizando SCEP (Simple Certificate Enrollment Protocol, RFC 8894). O perfil de WiFi de funcionários mudou então para EAP-TLS. O PEAP manteve-se ativo no mesmo serviço RADIUS durante toda a transição. A atribuição dinâmica de VLAN colocou os tablets do serviço de quartos num segmento diferente dos portáteis da área financeira.

Resultado. As contas de WiFi partilhadas reduziram-se a zero. Um tablet perdido custa agora uma única revogação de certificado em vez de uma reposição de palavra-passe em dezenas de dispositivos. A rotação de palavras-passe deixou de interromper o WiFi, porque já não existe nenhuma palavra-passe de WiFi. Pode encontrar mais informações sobre redes no setor hoteleiro na nossa página de Hotéis.

Quando é que o PEAP é a escolha certa?

Escolha o PEAP quando não puder colocar um certificado no dispositivo e a pessoa que inicia sessão tiver uma conta no diretório.

• Funcionários em telemóveis pessoais sob uma política BYOD (traga o seu próprio dispositivo), onde a inscrição no MDM não é aceitável.
• Prestadores de serviços, pessoal temporário de eventos e trabalhadores temporários com contas de curta duração.
• Infraestruturas com Active Directory mas sem PKI, como um passo intermédio rumo ao EAP-TLS.

O PEAP é aceitável para estes casos apenas se existirem três controlos implementados.

1. Bloqueie a validação do certificado do servidor em todos os dispositivos. Indique a CA de confiança e o nome exato do servidor. Implante-o através de Política de Grupo, de um perfil MDM ou de uma ferramenta de integração, nunca manualmente.
2. Mantenha o certificado do servidor previsível. Emita-o a partir de uma CA em que os seus dispositivos já confiam e mantenha o nome do servidor estável durante as renovações.
3. Reforce a palavra-passe do diretório. O PEAP é apenas tão forte quanto a palavra-passe dentro do túnel. Imponha o comprimento e bloqueie palavras-passe sabidamente comprometidas no diretório.

Cenário prático: um centro de conferências com pessoal sazonal

Situação. Um local de conferências e eventos no centro da cidade contrata cerca de 300 trabalhadores temporários em cada época alta. Estes utilizam os seus próprios telemóveis para aplicações de escalas e rádio. O local não pode pedir-lhes para inscreverem telemóveis pessoais num MDM. Até então, uma palavra-passe partilhada WPA2-Personal estava afixada no quadro de avisos da sala de pessoal.

O que foi feito. O departamento de TI criou uma conta de diretório com uma data de fim para cada trabalhador temporário. O WiFi para o pessoal mudou para PEAP. Um perfil de integração de utilização única fixou a AC e o nome do servidor em cada telemóvel. As contas são desativadas automaticamente na data de fim do contrato. Os participantes permaneceram numa rede separada de Captive Portal.

Resultado. A palavra-passe partilhada foi retirada. Quem sai perde agora o acesso na sua data de fim e não na alteração seguinte de palavra-passe. Cada ligação do pessoal corresponde a uma conta nominal nos registos RADIUS, que a equipa de segurança pode auditar após cada evento.

Quanto custa a execução do EAP-TLS e do PEAP?

Nenhum dos protocolos tem taxa de licença. Ambos estão integrados no Windows, macOS, iOS, Android e ChromeOS. O custo reside na infraestrutura e no tempo do pessoal.

Onde o EAP-TLS despende

O EAP-TLS concentra o custo no início. Paga por uma PKI e pelo tempo do pessoal para conceber modelos de certificados, inscrição e revogação. Se já utiliza um MDM, grande parte do custo de implementação está coberta. Após o lançamento, a principal tarefa recorrente é a renovação de certificados, que um MDM automatiza.

Onde o PEAP despende

O PEAP começa de forma económica, mas custa mais com o passar do tempo. Cada alteração de palavra-passe pode deixar credenciais desatualizadas em telemóveis e portáteis. Tentativas falhadas repetidas podem depois bloquear a conta no Active Directory, o que gera um tíquete no suporte técnico. Esses custos aumentam com o número de funcionários e com a frequência de rotação de palavras-passe.

Atenção ao tempo de vida do certificado do servidor

Se o seu certificado de servidor RADIUS for proveniente de uma AC pública, o seu tempo de vida está a diminuir. A Ballot SC-081 do CA/Browser Forum reduz os tempos máximos de vida dos certificados TLS públicos em etapas. O limite cai para 200 dias a partir de março de 2026 e para 47 dias a partir de março de 2029. Muitas equipas emitem o certificado RADIUS a partir de uma AC privada, o que mantém as renovações no seu próprio calendário.

O custo de errar

O Cost of a Data Breach Report 2024 da IBM fixou o custo médio global de uma violação em 4,88 milhões de USD. As credenciais roubadas ou comprometidas estiveram entre os vetores de ataque iniciais mais comuns nesse relatório. O EAP-TLS remove as palavras-passe de WiFi da superfície de ataque para todos os dispositivos que abrange.

Cenário prático: um retalhista com 120 lojas

Situação. Um retalhista opera 120 lojas com scanners portáteis e dispositivos móveis de ponto de venda em PEAP. Os dispositivos partilham uma conta de serviço. Cada rotação agendada dessa conta causava falhas de autenticação durante a noite nas lojas onde os dispositivos mantinham a palavra-passe antiga.

O que foi feito. As TI migraram os scanners e dispositivos de pagamento para EAP-TLS, utilizando o MDM que já operavam. Cada dispositivo recebeu o seu próprio certificado. Os telefones dos funcionários das lojas mantiveram-se em PEAP, numa VLAN separada sem rota para o ambiente de dados de portadores de cartão.

Resultado. As interrupções no dia da rotação pararam, porque os dispositivos no âmbito deixaram de depender de uma palavra-passe partilhada. A revogação passou a ser por dispositivo em vez de ser por loja. As verificações trimestrais de pontos de acesso não autorizados ao abrigo do requisito 11.2.1 do PCI-DSS continuaram sem alterações. Veja a nossa página de Retalho para saber mais sobre redes de lojas.

O que quebra cada protocolo e como pode preveni-lo?

Certificados expirados

Se o certificado da CA ou o certificado do servidor RADIUS expirar, todas as autenticações falham em simultâneo. Isto afeta tanto o EAP-TLS como o PEAP. Configure alertas para 90, 30 e sete dias antes de cada data de expiração e nomeie um responsável para cada certificado.

Validação de servidor desativada

Um perfil PEAP que ignora a validação do servidor entrega credenciais a qualquer evil twin. Audite os perfis de dispositivos regularmente e adicione a verificação à sua revisão de segurança. Remova quaisquer instruções de configuração manual que digam à equipa para tocar em "Não validar".

Latência de RADIUS e pontos únicos de falha

A autenticação encontra-se no caminho crítico. Uma latência elevada entre o controlador, o servidor RADIUS e o diretório causa timeouts de EAP. Execute o RADIUS com redundância ou utilize RADIUS na nuvem com mais do que uma região. Para propriedades distribuídas, como estações e material circulante em Comboios, coloque um proxy RADIUS local perto dos pontos de acesso.

Pontos de acesso não autorizados (rogue access points)

Utilize a deteção de intrusões sem fios integrada na sua plataforma de pontos de acesso para assinalar dispositivos não autorizados continuamente. Se aceita pagamentos com cartão, o requisito 11.2.1 do PCI-DSS exige que teste a existência de pontos de acesso não autorizados pelo menos a cada três meses.

Uma rede plana após a autenticação

Um início de sessão 802.1X bem-sucedido não deve abrir toda a rede. Utilize a atribuição dinâmica de VLAN, em que o RADIUS devolve a VLAN (LAN virtual) para cada dispositivo utilizando os atributos definidos na RFC 3580. Os dispositivos de pagamento, os telefones dos funcionários e os sistemas do edifício ficam então em segmentos separados com os seus próprios controlos de acesso.

Como decide para a sua infraestrutura?

Comece pela propriedade do dispositivo, não pela preferência de protocolo. A matriz abaixo mapeia situações comuns para uma recomendação.

O iPSK (identity pre-shared key, também chamado PPSK) dá a cada dispositivo ou grupo a sua própria chave WiFi num único nome de rede. Utilize-o para dispositivos que não conseguem executar um suplicante 802.1X.

Um caminho em quatro etapas até à decisão

1. Faça o inventário dos dispositivos por propriedade. Divida-os em geridos pela empresa, pessoais, sem ecrã (headless) e convidados.
2. Verifique o que já executa. Um MDM existente torna o EAP-TLS para dispositivos geridos num projeto modesto.
3. Defina o estado pretendido. EAP-TLS para todos os dispositivos geridos, PEAP apenas onde o registo for impossível.
4. Migre sem interromper o serviço. Execute ambos os métodos num único serviço RADIUS, mude os dispositivos geridos para EAP-TLS e, em seguida, desative os respetivos perfis PEAP.

Onde se enquadra a Purple?

A Purple é independente de hardware. Funcionamos como uma sobreposição na nuvem em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Não há necessidade de substituir infraestruturas existentes. A Purple é integrada sobre a rede que executa hoje.

Para funcionários e residentes, as redes baseadas em identidade da Purple associam o acesso a WiFi de funcionários e WiFi multinquilino à respetiva identidade. Funcionam através de RADIUS-as-a-Service na nuvem ligado ao Microsoft Entra ID, Okta ou Google Workspace. As entradas, mudanças e saídas são então tratadas a partir do diretório e não manualmente. Os dispositivos que não conseguem executar 802.1X obtêm iPSK.

Para convidados, o Guest WiFi da Purple oferece um Captive Portal - uma página web apresentada antes do acesso - com opt-ins de escolha consciente. Também suporta OpenRoaming, a federação da Wireless Broadband Alliance construída sobre Passpoint. O OpenRoaming permite que os dispositivos que regressam se liguem automaticamente através de uma ligação encriptada. O plano Connect da Purple inclui um fornecedor de identidade para OpenRoaming. O WiFi Analytics transforma depois essas ligações em dados de primeira parte sobre o tempo de permanência e visitas repetidas.

A Purple opera em mais de 80 000 locais ativos e geriu 440 milhões de logins em 2024 (dados próprios da Purple). A Purple tem certificação ISO 27001, está em conformidade com o GDPR e tem certificação Cyber Essentials.

Perguntas frequentes

O EAP-TLS é mais seguro do que o PEAP?

Sim. O EAP-TLS autentica ambas as partes através de certificados, pelo que não existe qualquer palavra-passe para ser alvo de phishing, adivinhada ou capturada por um ponto de acesso malicioso. O PEAP protege uma palavra-passe dentro de um túnel encriptado. A sua segurança depende da validação do certificado do servidor por cada dispositivo. Quando bem configurado, o PEAP é aceitável para dispositivos pessoais. Para dispositivos da empresa, terminais de pagamento e equipamento clínico, o EAP-TLS elimina toda uma classe de ataques a credenciais.

O PCI-DSS exige EAP-TLS para redes sem fios?

Não. O PCI-DSS v4.0 não especifica um método EAP. Exige criptografia forte em redes sem fios que transportem dados de titulares de cartões e verificações trimestrais para pontos de acesso não autorizados ao abrigo do requisito 11.2.1. Também define controlos de palavras-passe onde quer que estas sejam utilizadas. O EAP-TLS retira as palavras-passe de WiFi do escopo para os dispositivos abrangidos, o que reduz o seu trabalho de documentação. O PEAP também pode cumprir os requisitos, desde que a validação do servidor e a política de palavras-passe sejam aplicadas e documentadas.

Podemos migrar do PEAP para o EAP-TLS sem tempo de inatividade?

Sim. Um único serviço RADIUS pode aceitar ambos os métodos no mesmo nome de rede. Cada dispositivo utiliza o método especificado no seu perfil. Emita os certificados e envie o novo perfil EAP-TLS através do seu MDM, acompanhando depois os registos do RADIUS à medida que os dispositivos mudam. Quando já não existirem dispositivos geridos a autenticar-se com PEAP, remova os respetivos perfis PEAP. Mantenha o PEAP apenas para os dispositivos pessoais que não possa registar.

Precisamos de um MDM para executar o EAP-TLS?

Na prática, para mais do que um punhado de dispositivos, sim. Cada dispositivo necessita de um certificado, de uma CA de confiança e de um perfil de WiFi. Cada certificado também precisa de ser renovado antes de expirar. Um MDM como o Microsoft Intune automatiza este processo através do SCEP ou de um protocolo de registo semelhante. Sem ele, uma ferramenta de integração pode instalar certificados em dispositivos pessoais, mas a instalação manual não é viável para além de um projeto-piloto.

Qual é o custo do EAP-TLS em comparação com o PEAP?

Nenhum dos protocolos tem custos de licença. A diferença reside na infraestrutura e no tempo da equipa. O PEAP precisa de um serviço RADIUS, de um certificado de servidor e de um diretório que provavelmente já possui. O EAP-TLS adiciona uma PKI, na nuvem ou no local, e um MDM para distribuir e renovar certificados. Se já paga por um MDM, o custo extra é principalmente a PKI. Em troca, as redefinições de palavras-passe de WiFi e os bloqueios por rotação desaparecem.

O Purple funcionará com os pontos de acesso que já possuímos?

Sim. O Purple é agnóstico em relação ao hardware e funciona como uma sobreposição na nuvem em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Todos estes suportam 802.1X com um servidor RADIUS externo. Os seus pontos de acesso não limitam a escolha entre EAP-TLS e PEAP. Não é necessário substituir equipamentos: o Purple integra-se diretamente na rede que utiliza atualmente.

Os convidados devem utilizar EAP-TLS ou PEAP?

Não. Ambos os protocolos pressupõem uma pessoa conhecida ou um dispositivo gerido, e os convidados de hotéis, estádios e estações não são nenhum dos dois. Utilize um captive portal para aceitações e termos de utilização. Utilize o OpenRoaming, baseado no Passpoint, para que os dispositivos que regressam se liguem automaticamente através de uma ligação encriptada. O Guest WiFi da Purple abrange ambos, e o plano Connect inclui um fornecedor de identidade para OpenRoaming.

O PEAP ainda é seguro para utilizar em 2026?

Sim, dentro de certos limites. O PEAP com validação de certificado de servidor bloqueada e palavras-passe de diretório fortes continua a ser uma escolha razoável para dispositivos pessoais. O seu papel está a diminuir no Windows, onde o Credential Guard bloqueia credenciais MSCHAPv2 guardadas. A Microsoft recomenda, em alternativa, a autenticação baseada em certificados. Planeie EAP-TLS para todos os dispositivos Windows geridos e mantenha o PEAP para os dispositivos que não controla.