As melhores palavras-passe nunca saem do seu dispositivo

As palavras-passe são um problema. São um problema por razões que são desconhecidas para a maioria das pessoas que as usam. Uma palavra-passe que deixa a sua posse vai, garantidamente, sacrificar a segurança, independentemente da sua complexidade ou da dificuldade em a adivinhar.

A maioria dos leitores reconhecerá imediatamente que as palavras-passe são difíceis de recordar e gerir, especialmente à medida que os requisitos das palavras-passe ficam cada vez mais complexos. Felizmente, existem grandes pacotes de software e complementos de navegador para ajudar a gerir palavras-passe. A maioria dos leitores, no entanto, pode ficar surpreendida ao saber que os problemas são muito mais profundos do que é comumente conhecido. Todos eles são causados por as palavras-passe serem inerentemente inseguras.

Poderá dizer, “mas as palavras-passe são sempre armazenadas em formato encriptado!” Isso é verdade, mas está incompleto. A verdade é que mesmo uma palavra-passe encriptada pode ser quebrada, embora (e felizmente) com enorme esforço, quando são encriptadas corretamente. Um problema cada vez mais premente decorre da natureza das próprias palavras-passe: para usar uma palavra-passe diretamente, esta palavra-passe tem de ser manuseada "às claras".

Poderá dizer, “mas a minha palavra-passe é transmitida de forma segura através de HTTPS!” Isso é verdade.

Você diz, “mas eu sei que o servidor armazena a minha palavra-passe em forma encriptada e segura para que ninguém a possa aceder!” Bem, isso coloca muita fé sobre o servidor. Mesmo assim, vamos apenas dizer que sim, isso também pode ser verdade.

Resta, no entanto, uma ressalva importante - uma lacuna no uso de ponta-a-ponta das palavras-passe. Considere que, uma vez que um servidor recebe uma palavra-passe, entre ser transmitido de forma segura e armazenada em segurança, esta tem de ser lida e processada. Sim, como texto simples!

E piora ainda mais - por tanta gente estar habituada a pensar em software, é fácil esquecer a vulnerabilidade do hardware. Isto significa que, mesmo que o software seja confiável de uma qualquer forma, a palavra-passe tem de, a dada altura, residir numa memória. A palavra-passe tem de, a dada altura, ser transmitida por um barramento partilhado para a CPU. Estes fornecem vetores de ataque a outros intervenientes em inúmeras formas. É claro que esses vetores de ataques são muito mais improváveis do que os apresentados pela transmissão e armazenamento permanente, mas não são menos graves (vulnerabilidades recentes da CPU, como o Spectre e o Meltdown, devem servir como um severa lembrança).

A única forma de corrigir esse problema é livrarmo-nos completamente das palavras-passe. Há esperança! As comunidades de pesquisa e do setor privado estão a trabalhar arduamente para fazer exatamente isso. Estão a emergir e a amadurecer novos padrões. Infelizmente, as palavra-passe são tão onipresentes que levará muito tempo para concordar e suplantar as palavras-passe com novos padrões e tecnologias

Na Cloudflare, temos perguntado se há algo que possa ser feito agora, no imediato. O profundo olhar de hoje no OPAQUE é uma resposta possível. O OPAQUE é um entre muitos exemplos de sistemas que permitem que uma palavra-passe seja útil sem que nunca saia da sua posse. Ninguém gosta de palavras-passe, mas enquanto estiverem em uso, podemos garantir, pelo menos, que nunca sejam entregues.

Sou a primeira a admitir que a autenticação por palavra-passe é aborrecida. As palavras-passe são difíceis de recordar, é moroso introduzi-las e são notoriamente inseguras. As iniciativas para reduzir ou substituir as palavras-passe são promissoras. O WebAuthn, por exemplo, é um padrão para autenticação na web baseado principalmente em encriptação de chave pública usando "tokens" de hardware (ou software). Mesmo assim, as palavras-passe são de uma predominância frustrante enquanto mecanismo de autenticação. Independentemente dessa sua predominância se dever à sua facilidade de implementação, à familiaridade junto dos utilizadores ou simplesmente à sua onipresença na web e não só, nós gostaríamos de tornar a autenticação baseada nas palavras-passe o mais segura possível enquanto for usada.

O meu estágio na Cloudflare centrou-se no OPAQUE, um protocolo criptográfico que soluciona um dos problemas de segurança mais flagrantes com autenticação baseada em palavra-passe na Web: embora as palavras-passe sejam normalmente protegidas em trânsito por HTTPS, os servidores lidam com elas em texto simples para verificar a sua exatidão. A manipulação de palavras-passe em texto é perigosa, pois registar ou armazená-las em cache acidentalmente pode causar uma violação catastrófica. O objetivo do projeto, em vez de defender a adoção de qualquer protocolo específico, é demonstrar que o OPAQUE é uma opção viável entre muitas para autenticação. Como o caso da Web me é mais familiar e, provavelmente, para muitos leitores, usarei a Web como o meu exemplo principal.

O que acontece quando digita uma palavra-passe na web? O site precisa de verificar se a palavra-passe que digitou é a mesma com que se registou originalmente no site. Mas como é que essa verificação funciona?

Normalmente, o seu nome de utilizador e a palavra-passe são enviados para um servidor. De seguida, o servidor verifica se a palavra-passe registada associada ao seu nome de utilizador corresponde à palavra-passe que forneceu. Obviamente, para prevenir que um invasor observe o seu tráfego de Internet e roube a sua palavra-passe, a sua ligação ao servidor deve ser encriptada por HTTPS (HTTP-over-TLS) [HTTPS].

Apesar do uso de HTTPS, ainda permanece um problema gritante neste fluxo: o servidor tem de armazenar uma representação da sua palavra-passe algures. Os servidores são difíceis de proteger e as violações são muito comuns. Vazar essa representação pode causar problemas de segurança catastróficos. (Para registos das últimas violações, consulte https://haveibeenpwned.com/).

Para tornar essas fugas menos devastadoras, os servidores geralmente aplicam uma função "hash" às palavras-passe do utilizador. Uma função "hash" mapeia cada palavra-passe para um valor único e aleatório. Apesar de ser fácil aplicar o "hash" a uma palavra-passe, é quase impossível reverter a função e recuperar a palavra-passe. (Dito isto, qualquer um pode adivinhar uma palavra-passe, aplicar a função "hash" e verificar se o resultado é o mesmo.)

Com a aplicação do "hash" às palavras-passe, as palavras-passe em texto já não são armazenadas nos servidores.  Um invasor que roube uma base de dados de palavras-passe deixa de ter acesso instantâneo a elas. Em vez disso, o invasor tem de aplicar o "hash" a muitas palavras-passe possíveis e comparar os resultados com os "hashes" da divulgação.

Infelizmente, se o servidor apenas aplicar o "hash" às palavras-passes, os invasores podem descarregar tabelas arco-íris pré-computadas, contendo "hashes" de biliões de palavras-passe possíveis, recuperando quase instantaneamente as palavras-passe em texto simples. (Consulte https://project-rainbowcrack.com/table.htm para ver uma lista de algumas tabelas de arco-íris).

Neste sentido, uma boa estratégia de "defesa em profundidade" é usar "hashing" com "sal" , onde o servidor faz "hash" à sua palavra-passe anexada a um valor aleatório por utilizador - denominado "sal". O servidor também guarda o "sal" junto ao nome de utilizador, para que o utilizador nunca o veja ou precise de o enviar. Quando o utilizador submete uma palavra-passe, o servidor calcula novamente essa função de "hash" usando o "sal". Um invasor que rouba dados de palavras-passe, i.e. as representações de palavras-passe e valores "sal", terá de adivinhar palavras-passe comuns uma a uma e aplicar a função "hash" ("salgada") a cada palavra-passe adivinhada. As tabelas arco-íris existentes não serão de grande ajuda, uma vez que não consideram os "sais". Assim, o invasor precisará de criar uma nova tabela arco-íris para cada utilizador!

Isto (assim se espera) contém o ataque durante tempo suficiente para que o serviço informe os utilizadores de uma fuga, para que eles possam mudar suas palavras-passe. Além disso, os "hashes" com "sais" devem ser endurecidos aplicando um "hash" muitas vezes, para abrandar os ataques. (Consulte https://blog.cloudflare.com/keeping-passwords-safe-by-staying-up-to-date/ para ver uma discussão mais detalhada).

Estas duas estratégias de mitigação -- encriptar a palavra-passe em trânsito e armazenar "hashes" com "sais" e endurecidos -- constituem as boas-práticas atuais.

Permanece aberto um grande buraco de segurança. O palavra-passe sobre TLS (Password-over-TLS) (como vamos chamá-lo) requer que os utilizadores enviem palavra-passe em texto simples para servidores ao iniciar sessão, porque os servidores devem ver essas palavras-passe para as corresponder com as que estão registadas em arquivo. Mesmo um servidor bem-intencionado poderia acidentalmente armazenar em cache ou registar as suas tentativas de palavra-passe, ou ficar corrompido no decorrer da verificação de palavras-passe. (Por exemplo, o Facebook percebeu em 2019 que tinha vindo a armazenar acidentalmente centenas de milhões de palavras-passe de utilizadores em texto simples). Idealmente, os servidores nunca deveriam sequer ver uma palavra-passe em texto simples.

E aqui está o busílis da questão: como é possível verificar uma palavra-passe se nunca a consegue ver? Eis que entra o OPAQUE: um protocolo Password-Authenticated Key Exchange (PAKE - Troca de Chave Autenticada por Palavra-passe) que comprova simultaneamente o conhecimento de uma palavra-passe e deriva uma chave secreta. Antes de descrever o OPAQUE em detalhe, vamos resumir primeiro as funcionalidades do PAKE em geral.

O Password-Authenticated Key Exchange (PAKE) foi proposto por Bellovin e Merrit[1] em 1992, com a motivação inicial de permitir a autenticação por palavra-passe sem a possibilidade de ataques de dicionário baseados em informação passada por um canal inseguro.

Essencialmente, um PAKE simples ou simétrico, é um protocolo criptográfico que permite que duas partes que partilham apenas uma palavra-passe estabeleçam uma chave secreta partilhada forte. Os objetivos do PAKE são:

1. As chaves secretas correspondem caso as palavras-passe coincidam e parecem aleatórias caso contrário.

2. Os participantes não precisam de confiar em terceiros (em particular, nenhuma infraestrutura de chave pública).

3. A chave secreta resultante não é assimilada por ninguém que não faça parte do protocolo - incluindo aqueles que conhecem a palavra-passe.

4. O protocolo não revela a palavra-passe de nenhuma das partes a nenhuma delas (a menos que as palavras-passe correspondam), nem a curiosos.

Em suma, a única maneira de ter êxito num ataque ao protocolo é adivinhar a palavra-passe corretamente ao mesmo tempo que se participa no protocolo. (Felizmente, tais ataques podem ser principalmente frustrados por limitação de taxa, ou seja, bloqueando o início de sessão de um determinado utilizador após um certo número de tentativas de palavras-passe incorretas).

Devido a esses requisitos, a palavra-passe sobre TLS ("password-over-TLS") não é claramente um PAKE, pois:

• É baseado em WebPKI, confiando em terceiros denominados de Autoridades de Certificação (consulte https://blog.cloudflare.com/introducing-certificate-transparency-and-nimbus/ para ver uma explicação aprofundada sobre WebPKI e algumas das suas falhas).

• A palavra-passe do utilizador é revelada ao servidor.

• A Palavra-passe sobre TLS ("password-over-TLS") não dá ao utilizador qualquer garantia de que o servidor conheça a sua palavra-passe ou uma derivada dela - um servidor poderia aceitar qualquer entrada do utilizador sem qualquer verificação.

Dito isto, a PAKE simples ainda é pior do que a palavra-passe sobre TLS ("password-over-TLS"), simplesmente porque requer que o servidor armazene palavras-passe de texto simples. Precisamos de uma PAKE que permita ao servidor armazenar "hashes" com "sais" se quisermos suplantar a prática atual.

Uma melhoria em relação ao PAKE simples é o que é chamado dePAKE assimétrico (aPAKE), porque apenas o cliente conhece a palavra-passe; e o servidor conhece uma palavra-passe com "hash" . Um aPAKE tem as quatro propriedades do PAKE, além de mais uma:

1. Um invasor que roube dados de palavra-passe armazenados no servidor tem de executar um ataque de dicionário para aceder à palavra-passe.

O problema com a maioria dos protocolos aPAKE existentes, contudo, é não permitirem um "hash" com "sal" (ou, se o fizerem, exigem que o "sal" seja transmitido ao utilizador, o que significa que o invasor tem acesso ao "sal" de antemão e pode começar a computar uma tabela arco-íris para o utilizador, antes de roubar quaisquer dados). Gostaríamos, portanto, de atualizar a propriedade de segurança da seguinte forma:

5*)Um invasor que roube dados de palavra-passe armazenados no servidor tem de executar um ataque de dicionário por cada utilizador, para aceder à palavra-passe depois do comprometimento da informação.

O OPAQUE é o primeiro protocolo aPAKE que conta com uma prova de segurança formal incorporando esta propriedade: permite um "sal" completamente secreto.

O OPAQUE é o que é referido como um_a PAKE forte_, o que significa simplesmente que ele resiste a esses ataques de pré-computação usando um "hash" secretamente "salgado" no servidor. O OPAQUE foi proposto e formalmente analisado por Stanislaw Jarecki, Hugo Krawcyzk e Jiayu Xu em 2018 (divulgação completa: Stanislaw Jarecki é meu conselheiro académico). O nome OPAQUE é uma combinação dos nomes de dois protocolos criptográficos: OPRF e PAKE. Já conhecemos o PAKE, mas o que é um OFRF? OFRF significa "Oblivious Pseudo-Random Function", que é um protocolo pelo qual duas partes calculam uma função F(chave, x) que é determinística, mas produz valores de aparência aleatória. Uma parte introduz o valor x e a outra parte introduz a chave - a parte que introduz o x fica a conhecer o resultado de F (chave, x) mas não a chave, e a parte que fornece a chave não fica a saber nada. (Pode atirar-se à matemática dos OPRFs aqui: https://blog.cloudflare.com/privacy-pass-the-math/).

O cerne do OPAQUE é um método para armazenar segredos de utilizador para que fiquem seguros num servidor, sem dar ao servidor acesso a esses segredos. Em vez de armazenar um "hash" de palavra-passe com "sal" tradicional, o servidor armazena um envelope secreto para si, que está “bloqueado” por duas informações: a sua palavra-passe, conhecida apenas por si e uma chave secreta aleatória (como um "sal"), conhecida apenas pelo servidor. Para iniciar sessão, o cliente inicia um intercâmbio criptográfico que revela a chave do envelope ao cliente, mas, mais importante, não ao servidor.

Em seguida, o servidor envia o envelope para o utilizador, que pode agora recuperar as chaves encriptadas. (As chaves incluídas no envelope são um par de chaves públicas/privadas para o utilizador e uma chave pública para o servidor.) Essas chaves, uma vez desbloqueadas, serão as entradas para um protocolo de "Authenticated Key Exchange" (AKE), que permite que o utilizador e o servidor definam uma chave secreta que possa ser usada para encriptar a sua comunicação futura.

O OPAQUE consiste em duas fases, que são registo de credenciais e início sessão por troca de chaves.

Antes do registo, o utilizador inscreve-se primeiro num serviço e escolhe um nome de utilizador e a palavra-passe. O registo começa com o fluxo de OPRF que acabámos de descrever: Alice (a utilizadora) e Bob (o servidor) fazem uma troca de OPRF. O resultado é que a Alice tem uma chave aleatória rwd, derivada da saída do OFRF F(chave, pwd), onde a chave é uma chave OPRF propriedade do servidor específica para a Alice e pwd é a palavra-passe da Alice.

Dentro da sua mensagem OPRF, Bob envia a chave pública para a sua identidade OPAQUE. A Alice gera então um novo par de chaves privadas/públicas, que serão a sua identidade OPAQUE persistente para o serviço do Bob e encripta a sua chave secreta juntamente com a chave pública do Bob com o rwd (chamaremos o resultado do envelope encriptado). Ela envia este envelope encriptado a para da sua chave pública (não encriptada) para o Bob, que armazena os dados que ela forneceu, juntamente com o segredo OFRF específico da Alice num banco de dados indexado pelo seu nome de utilizadora.

A fase de início de sessão é muito semelhante. Começa da mesma forma que o registo - com um fluxo OFRF. No entanto, no lado do servidor, em vez de gerar uma nova chave OPRF, Bob procura a que criou durante o registo da Alice. Ele faz isso ao procurar o nome de utilizadora da Alice (que ela fornece na primeira mensagem) e recuperando o seu registo dela. Este registo contém a chave pública dela, o seu envelope encriptado e a chave OPRF do Bob para a Alice.

Ele também envia o envelope encriptado que a Alice pode desencriptar com o resultado do fluxo OPRF. (Se a desencriptação falhar, ela interrompe o protocolo - isto provavelmente indica que ela digitou a sua palavra-passe erradamente, ou que o Bob não é quem diz que ser). Se a desencriptação for bem-sucedida, ela fica agora com a sua própria chave secreta e com a chave pública do Bob. Ela insere-as num protocolo AKE com o Bob, que, por sua vez, introduz a sua chave privada e a sua chave pública, o que lhes dá uma nova chave secreta partilhada.

Uma pergunta importante a fazer aqui é: qual é o AKE que é o adequado para o OPAQUE? A especificação CFRG emergente descreve várias opções, incluindo 3DH e SIGMA-I. No entanto, na Web, já temos um AKE à nossa disposição: o TLS!

Lembre-se de que o TLS é um AKE porque fornece autenticação unilateral (e mútua) com derivação secreta partilhada. O núcleo do TLS é uma troca de chaves Diffie-Hellman, que por si só não é autenticada, o que significa que as partes que a executam não têm como verificar com quem a estão a executar. (Isto é um problema porque quando inicia sessão no seu banco, ou em qualquer outro site que armazene os seus dados privados, quer ter certeza de que eles são quem dizem ser). A autenticação usa principalmente certificados, que são emitidos por entidades confiáveis através de um sistema chamado Public Key Infrastructure (PKI). Cada certificado é associado a uma chave secreta. Para provar a sua identidade, o servidor apresenta o seu certificado ao cliente e assina o "handshake TLS" com a sua chave secreta.

Modificar esta autenticação omnipresente baseada em certificado na Web talvez não seja o melhor sítio para começar. Em vez disso, uma melhoria seria autenticar o segredo TLS partilhado, usando o OPAQUE, depois do "handshake TLS" estar concluído. Por outras palavras, uma vez que um servidor é autenticado com o seu certificado WebPKI típico, os clientes poderiam autenticar-se subsequentemente ao servidor. Esta autenticação poderia ocorrer no “pós-handshake” na ligação TLS usando o OPAQUE.

Autenticadores Exportados são um mecanismo para autenticação “pós-handshake” no TLS. Permitem que um servidor ou cliente forneça prova de uma identidade sem configurar uma nova ligação TLS. Lembre-se de que, no caso da Web padrão, o servidor estabelece a sua identidade com um certificado (provando, por exemplo, que eles são a “cloudflare.com”). Mas se o mesmo servidor também tiver identidades alternativas, eles devem executar o TLS novamente para provar quem são.

O fluxo básico do Autenticador Exportado assemelha-se a um protocolo clássico de resposta a desafios e funciona da seguinte forma. (Consideraremos apenas o caso de autenticação do servidor, pois o caso do cliente é simétrico).

A qualquer momento depois de uma ligação TLS ser estabelecida, Alice (a cliente) envia uma solicitação de autenticador para indicar que gostaria que o Bob (o servidor) provasse uma identidade adicional. Esta solicitação inclui um contexto (uma sequência imprevisível - pense nela como um desafio) e extensões que incluem informações sobre que identidade o cliente deseja receber. Por exemplo, o cliente pode incluir a extensão SNI para pedir ao servidor um certificado associado a um determinado nome de domínio diferente daquele usado inicialmente na ligação TLS.

Ao receber a mensagem do cliente, se o servidor tiver um certificado válido correspondente à solicitação, devolverá um autenticador exportado, que comprova que ele detém a chave secreta para o certificado. (Essa mensagem tem o mesmo formato que uma mensagem de autenticação do cliente no handshake TLS 1,3 - contém um Certificado, uma Verificação de Certificado e uma mensagem Concluído). Se o servidor não puder ou não quiser autenticar com o certificado solicitado, ele responderá com um autenticador vazio que contém apenas uma mensagem de Concluído bem formada.

Depois disso, o cliente certifica-se de que o Autenticador Exportado que recebe está bem formado e verifica depois se o certificado apresentado é válido. Em caso afirmativo, aceita a nova identidade.

Em suma, os Autenticadores Exportados são uma maneira de fazer a autenticação numa camada superior (como a camada de aplicações) com segurança, aproveitando os formatos de encriptação e de mensagem bem escrutinados do TLS. Além disso, está vinculado à sessão TLS para que as mensagens de autenticação não possam ser copiadas e coladas de uma ligação TLS para outra. Por outras palavras, os Autenticadores Exportados fornecem exatamente os ganchos corretos necessários para adicionar autenticação baseada em OPAQUE ao TLS.

OPAQUE-EA permite que o OPAQUE seja executado em qualquer ponto após uma ligação TLS já ter sido configurada. Lembre-se de que o Bob (o servidor) armazenará a sua identidade OPAQUE, neste caso, uma chave de assinatura e chave de verificação e a Alice armazenará a sua identidade - encriptada - no servidor do Bob. (O fluxo de registo onde a Alice armazena as suas chaves encriptadas é o mesmo que no OPAQUE normal, excetuando o facto de ela armazenar uma chave de assinatura, portanto vamos saltar diretamente para o fluxo de início de sessão). A Alice e o Bob executam dois fluxos EA autenticados por solicitação, um para cada parte, e as mensagens de protocolo OPAQUE vão igualmente na seção de extensões dos EAs. Vejamos em detalhe como isso funciona.

Primeiro, a Alice gera a sua mensagem OPRF baseada na sua palavra-passe. Cria uma Solicitação de Autenticador pedindo a identidade OPAQUE do Bob e inclui (no campo de extensões) o seu nome de utilizador e a sua palavra-passe oculta, enviando isso para o Bob pela sua ligação TLS estabelecida.

Bob recebe a mensagem e procura o nome de utilizador da Alice na sua base de dados. Acede ao seu registo OPAQUE, que contém a sua chave de verificação, o seu envelope encriptado e a sua chave OPRF. Usa a chave OPRF na palavra-passe oculta, criando um Autenticador Exportado que ateste a propriedade da sua chave de assinatura OPAQUE, com uma extensão que contém o seu resultado OPRF e o envelope encriptado. Além disso, envia uma nova Solicitação de Autenticação pedindo à Alice que comprove a propriedade da sua chave de assinatura OPAQUE.

A Alice analisa a mensagem e conclui a avaliação OPRF usando a mensagem do Bob para obter resultados rwd e usa rwd para desencriptar o envelope. Isso revela a sua chave de assinatura e a chave pública do Bob. Ela usa a chave pública do Bob para validar a sua prova de Resposta do Autenticador e, se estiver correta, cria e envia um Autenticador Exportado comprovando que ela detém a chave de assinatura recém-desencriptada. O Bob verifica a validade do seu Autenticador Exportado e, se estiver correta, aceita o seu início de sessão.

O descrito acima é apoiado por imensa teoria que ainda não arranjou maneira de ser colocada em prática. O meu projeto era transformar a teoria em realidade. Comecei pelas descrições escritas de Autenticadores Exportados, OPAQUE e por um esboço preliminar do OPAQUE-in-TLS. O meu objetivo era partir daí para um protótipo funcional.

A minha "demo" atesta que é viável implementar OPAQUE-EA na web, removendo completamente palavras-passe em texto simples na rede, ainda que estejam encriptadas. Isso fornece uma alternativa possível ao fluxo atual da Palavra-passe sobre TLS ("Password-over-TLS"), com melhores propriedades de segurança e sem nenhuma alteração visível para o utilizador.

Vale a pena conhecer alguns dos detalhes da implementação. Na ciência da computação, a abstração é uma ferramenta poderosa. Isto significa que, muitas vezes, podemos confiar em ferramentas e APIs existentes para evitar a duplicação de esforços. No meu projeto, apoiei-me bastante em mint, uma implementação de código aberto do TLS 1.3 em Go, que é ótima para fazer protótipos. Também usei a biblioteca CIRCL para OPRF. Criei bibliotecas para Autenticadores Exportados, o cerne do OPAQUE e o OPAQUE-EA (que une os dois).

Construí a demonstração para Web envolvendo a funcionalidade OPAQUE-EA num servidor HTTP simples e um cliente que passam mensagens entre si através de HTTPS. Uma vez que os navegadores não conseguem executar o Go, usei um compilador de Go para WebAssembly (WASM) para, assim, obter a funcionalidade Go no navegador, escrevendo um script simples em JavaScript para nomear as funções WASM de que precisava.

Como os navegadores atuais não dão acesso à ligação TLS subjacente do lado do cliente, tive de implementar um desvio para permitir que o cliente acedesse às chaves exportadoras, nomeadamente, para que o servidor simplesmente calculasse as chaves e as enviasse para o cliente através de HTTPS. Esta solução para contornar o problema reduz a segurança da demonstração resultante - significa que é dada confiança ao servidor para fornecer as chaves certas. Mesmo assim, a palavra-passe do utilizador ainda está segura, mesmo se um servidor malicioso fornecesse chaves más - eles simplesmente não têm garantias de que realmente se registaram nesse servidor antes. Contudo, no futuro, os navegadores podem incluir um mecanismo para suportar chaves exportadas e permitir que o OPAQUE-EA seja executado com as suas propriedades de segurança completas.

Pode explorar minha implementação no Github e até mesmo seguir as instruções para criar o seu próprio servidor de teste e cliente OPAQUE-EA. Gostaria de salientar, no entanto, que esta implementação serve apenas como "prova de conceito", não devendo ser utilizada para sistemas de produção sem uma revisão mais profunda.

Apesar das suas excelentes propriedades, existirão definitivamente alguns obstáculos em passar o OPAQUE-EA de uma "prova de conceito" para um mecanismo de autenticação de pleno direito.

Suporte de navegador para chaves de exportador TLS. Como mencionado há pouco, para executar o OPAQUE-EA num navegador, é necessário aceder a segredos da conexão TLS, a que chamamos chaves exportadoras. Não existe forma de o fazer nos atuais navegadores mais populares, portanto, será necessário adicionar um suporte para essa funcionalidade.

Reconfiguração de bases de dados de palavras-passe. Para adotar o OPAQUE-EA, além de atualizar a sua lógica de verificação de palavras-passe, os servidores precisarão também de reformular completamente as suas bases de dados de palavras-passe. Como o OPAQUE se baseia em representações especiais de palavra-passe que só podem ser geradas de forma interativa, as palavras-passe com "hash" e com "sal" existentes não podem ser atualizadas automaticamente para os registos OPAQUE. É provável que os servidores venham a precisar de executar um fluxo de registo OPAQUE especial para cada utilizador. Como o OPAQUE depende de "buy-in" tanto do cliente como do servidor, os servidores podem precisar de suportar o método antigo durante algum tempo, até que todos os clientes concluam o processo.

Confiança em padrões emergentes. O OPAQUE-EA baseia-se em OPRFs, que estão em processo de padronização, e em Autenticadores exportados, o padrão proposto. Isso significa que o suporte para essas bases ainda não está disponível na maioria das bibliotecas criptográficas existentes, o que significa que os primeiros a adotá-las podem vir a precisar de implementar essas ferramentas por conta própria.

Enquanto as pessoas continuarem a usar palavras-passe, gostaríamos de tornar esse processo o mais seguro possível. Os métodos atuais dependem da prática arriscada de lidar com palavras-passe em texto simples do lado do servidor, enquanto este verifica a sua exatidão. Os PAKES, e (especificamente, aPAKEs) permitem o início de sessão seguro com palavra-passe sem nunca deixar que o servidor as veja. O OPAQUE é um dos melhores aPAKEs disponíveis e que pode ser totalmente integrado no TLS. Pode consultar o código aquí.

[1] Bellovin, S. M., and Merritt, M. “Encrypted key exchange: Password-based protocols secure against dictionary attacks.” Proc. IEEE Computer Society Symposium on Research in Security and Privacy (Oakland, May 1992), 72–84.