Nos últimos dez anos, a Cloudflare tornou-se numa parte importante da Infraestrutura da Internet, alimentando sites, APIs e serviços da web para ajudá-los a tornarem-se mais seguros e eficientes. A internet não só está a crescer em termos de capacidade e de número de utilizadores, mas também em processo evolutivo no que toca ao seu design e funcionalidade. Enquanto principal player no ecossistema da Internet, a Cloudflare tem a responsabilidade de a ajudar a crescer de forma que ela respeite e acrescente valor aos seus utilizadores. Hoje lançamos diversos anúncios no âmbito de ajudar a melhorar os protocolos da Internet em relação a algo que é importante para os nossos clientes e utilizadores da Internet de todo o mundo: a privacidade.

Estas iniciativas são:

• Corrigir uma das últimas fugas de informação em HTTPS através do Encrypted Client Hello (ECH), conhecido anteriormente como Encrypted SNI

• Tornar o DNS ainda mais privado, dando suporte ao**"Oblivious DNS-over-HTTPS" (OdoH)**

• Desenvolver um protocolo superior para autenticação de palavra-passe, o "OPAQUE" , que torna mais improváveis as violações de palavra-passe.

Cada um destes projetos tem impacto sobre um aspecto da Internet que influencia as nossas vidas online e a nossa pegada digital. Saibamo-lo ou não, há imensa informação privada sobre nós e as nossas vidas à deriva online. Isto é algo que podemos ajudar a consertar.

Há mais de um ano que trabalhamos através de organizações de padrões, como o IETF, e em parceria com os maiores nomes de tecnologia da Internet (incluindo Mozilla, Google e Equinix, entre outros) para projetar, implementar e testar esses novos protocolos de preservação de privacidade à escala da Internet. Cada um destes três protocolos aborda um aspecto crítico das nossas vidas online, pelo que esperamos que ajudem a produzir melhorias reais na privacidade online à medida que ganham adoção.

Uma das principais missões da Cloudflare é apoiar e desenvolver tecnologia que ajude a construir uma Internet melhor. Enquanto indústria, fizemos progressos excecionais para tornar a Internet mais segura e robusta. A Cloudflare orgulha-se de ter desempenhado um papel neste progresso, através de múltiplas iniciativas ao longo dos anos.

Aqui estão alguns dos destaques:

• Universal SSL™. Temos sido uma das forças motrizes para encriptar a web. Lançámos o Universal SSL em 2014 para fornecer gratuitamente encriptação de sites aos nossos clientes e temos trabalhado ativamente com autoridades de certificação - como a Let's Encrypt, navegadores da web e operadores de sites para ajudar a remover conteúdo misto. Antes de o Universal SSL ser lançado para oferecer HTTPS gratuitamente a todos os clientes da Cloudflare, apenas 30% das ligações a sites eram encriptadas. Através dos esforços da indústria, esse número é agora 80% - e uma proporção muito maior do tráfego total de Internet. Além de fazer a nossa parte para encriptar a web, apoiámos o projeto Transparência de Certificados ("Certificate Transparency") através do Nimbus e do Merkle Town, o que melhorou a responsabilidade pelo ecossistema de certificados do qual o HTTPS depende pata ter confiança.

• TLS 1.3 e QUIC. Também fomos acérrimos defensores da atualização dos protocolos de segurança existentes. Consideremos o Transport Layer Security (TLS), o protocolo estrutural que protege o HTTPS. Os engenheiros da Cloudflare ajudaram a contribuir para a conceção do TLS 1.3, a versão de referência mais recente e, em 2016, lançámos o suporte para uma versão inicial do protocolo. Este lançamento inicial ajudou a conduzir a melhorias na versão final do protocolo. O TLS 1.3 é, agora, o protocolo de encriptação mais utilizado na web, sendo um componente chave do padrão QUIC emergente, que também fomos pioneiros a adotar.

• Proteger o Roteamento, Nomeação e a Hora. Fizemos grandes esforços para ajudar a proteger outros componentes críticos da Internet. Os nossos esforços para ajudar a proteger o roteamento da Internet através do nosso kit de ferramentas RPKI , estudo de medições e a nossa ferramenta “Is BGP Safe Yet” melhoraram significativamente a resistência da Internet contra fugas de roteamento causadoras de perturbações. O nosso serviço de hora (time.cloudflare.com) ajudou a manter os relógios das pessoas em sincronia com protocolos mais seguros, como o NTS e o Roughtime. Também tornámos o DNS mais seguro ao suportar o DNS-over-HTTPS e o DNS-over-TLS no 1.1.1.1 desde o lançamento, juntamente com o DNSSEC com um só clique no nosso serviço de DNS autoritário e no registrar.

Continuar a melhorar a segurança dos sistemas de confiança online é fundamental para o crescimento da Internet. No entanto, está em jogo um princípio ainda mais fundamental: o respeito. A infraestrutura subjacente à Internet deve ser concebida para respeitar os seus utilizadores.

Quando inicia sessão num site ou num serviço específicos que tenham uma política de privacidade, sabe o que é que esse site deve fazer com os seus dados. É explícito. Não existe, no entanto, nenhum acordo semelhante entre os utilizadores e os operadores da Internet propriamente dita. Pode ter um acordo com o seu Provedor de Serviços de Internet (ISP) e com o site que está a visitar, mas é muito improvável que saiba sequer que redes é que os seus dados estão a percorrer. A maioria das pessoas não tem um conceito da Internet para além do que veem no seu ecrã, por isso é difícil de imaginar que as pessoas aceitassem ou sequer que compreendessem o que é uma política de privacidade de um provedor de tráfego ou de uma "middlebox" de inspeção.

Sem encriptação, as informações de navegação na Internet são implicitamente partilhadas com inúmeros terceiros online, porquanto a informação vai passando entre as redes. Sem roteamento seguro, o tráfego dos utilizadores pode ser sequestrado e perturbado. Sem protocolos de salvaguarda da privacidade, a vida dos utilizadores online não é tão privada quanto eles pensam ou esperam. A infraestrutura da Internet não foi construída de uma forma que reflita as suas expectativas.

Diagrama de como o tráfego se move através de redes, com e sem fugas de roteamento.

A boa notícia é que a Internet está em constante evolução. Um dos grupos que ajuda a orientar essa evolução é o Internet Architecture Board (IAB), que providencia supervisão arquitetónica ao Internet Engineering Task Force (IETF), o principal órgão de definição de padrões para a Internet. O IAB publicou recentemente o RFC 8890, que afirma que os utilizadores finais individuais devem ser a prioridade aquando da conceção de protocolos de Internet. Declara que, se houver um conflito entre os interesses dos utilizadores finais e o interesse dos provedores de serviços, corporações ou governos, as decisões do IETF devem favorecer os utilizadores finais. Um dos principais interesses dos utilizadores finais é o direito à privacidade, pelo que o IAB publicou o RFC 6973 para indicar como os protocolos da Internet devem levar em conta a privacidade.

As publicações técnicas no blog de hoje são sobre melhorias na Internet que foram projetadas para respeitar a privacidade do utilizador. A privacidade é um tópico complexo e que abrange diversas disciplinas, por isso, é importante ser claro sobre o que queremos dizer com “melhorar a privacidade”. Falamos especificamente sobre alterar os protocolos que lidam com informações sensíveis em relação à privacidade e que agora estão expostas “on-the-wire” (na rede), modificando-as para que esses dados fiquem expostos a menos intervenientes. Esses dados continuam a existir, apenas já não estão disponíveis ou visíveis para terceiros sem criar um mecanismo que os recolha numa camada mais elevada da pilha da Internet, a camada de aplicações. Estas mudanças vão além da encriptação do site; atingem a fundo o design dos sistemas que são fundamentais para fazer da Internet o que ela é.

Duas ferramentas para garantir que os dados possam ser usados sem serem vistos são a criptografia e os proxy seguros.

A criptografia permite que a informação seja transformada num formato que um número muito limitado de pessoas (que têem a chave) pode compreender. Alguns descrevem a criptografia como uma ferramenta que transforma problemas de segurança de dados em problemas de gestão de chaves. Esta é uma descrição bem-humorada, mas justa. A criptografia torna mais fácil racionalizar a privacidade, pois apenas os titulares de chaves podem visualizar dados.

Outra ferramenta para proteger o acesso aos dados é o isolamento/segmentação. Ao limitar fisicamente que partes têm acesso aos dados, o utilizador constrói eficazmente muros de privacidade. Uma arquitetura comum é confiar nos proxy com reconhecimento de políticas para transmitir dados de um lugar para outro. Esses proxy podem ser configurados para retirar dados sensíveis ou bloquear transferências de dados entre as partes, de acordo com o que a política de privacidade diz.

Ambas as ferramentas são eficazes, individualmente, mas podem ser ainda mais eficazes se combinadas. O roteamento em cebola (a técnica criptográfica subjacente ao Tor) é um exemplo de como os proxies e a criptografia podem ser usados em conjunto para impor uma privacidade forte. No geral, se o sujeito A quiser enviar dados ao sujeito B, eles podem encriptar os dados com a chave do sujeito B e encriptar os metadados com uma chave de proxy, enviando-os para o proxy.

As plataformas e serviços construídos sobre a Internet podem incluir sistemas de consentimento, como as políticas de privacidade apresentadas através de interfaces de utilizador. A infraestrutura da Internet depende de camadas de protocolos subjacentes e, uma vez que essas camadas da Internet se encontram tão abaixo de onde o utilizador interage com elas, é quase impossível construir um conceito de consentimento do utilizador. Para respeitar os utilizadores e protegê-los contra problemas de privacidade, os protocolos que agregam a Internet devem ser projetados tendo a privacidade pré-ativada.

A transição de uma web maioritariamente não encriptada para uma web encriptada tem feito muito pela privacidade do utilizador final. Por exemplo, o “coffeeshop stalker” já não é um problema para a maioria dos sites. Ao aceder à maioria dos sites online, os utilizadores já não estão a difundir todos os aspetos da sua experiência de navegação na web (consultas de pesquisa, versões do navegador, cookies de autenticação, etc.) pela Internet, para que qualquer participante no caminho os possa ver. Se um site estiver configurado corretamente para usar HTTPS, os utilizadores podem ter certeza de que os seus dados estão seguros contra mirones e que alcançam apenas o destinatário pretendido, porque as suas ligações são encriptadas e autenticadas.

No entanto, o HTTPS protege apenas o conteúdo das solicitações da web. Mesmo que navegue apenas em sites sobre HTTPS, isso não significa que os seus padrões de navegação sejam privados. Isto acontece porque o HTTPS não consegue encriptar um aspecto importante da troca: os metadados. Quando faz uma chamada telefónica, os metadados representam o número de telefone, não o conteúdo da chamada. Os metadados são dados sobre os dados.

Para ilustrar a diferença - e o porquê de isso ser importante -, aqui está um diagrama do que acontece quando visita um site como uma galeria de imagens. Digamos que vai para uma página específica dessa galeria (https://.com/room101/) que tenha imagens específicas incorporadas hospedadas em .com.

O espaço dentro da linha tracejada representa aqui a parte da Internet de que os seus dados precisam para transitar. Incluem a sua rede local ou café, o seu ISP, podendo ser um provedor de tráfego de Internet ou a parte da rede do provedor de nuvem que aloja o servidor. Os utilizadores geralmente não têm uma relação com essas entidades, ou um contrato que impeça essas partes de fazer algo com os dados do utilizador. E mesmo se essas entidades não vissem os dados, um observador bem posicionado que intercetasse o tráfego da Internet poderia ver qualquer coisa que fosse enviada sem encriptação. Seria melhor se não o vissem, de todo. Neste exemplo, o facto de o utilizador ter visitado .com pode ser visto por um observador, o que é expectável. No entanto, apesar de o conteúdo da página estar encriptado, é possível saber que página específica visitou, uma vez que .com também fica visível.

A regra geral diz que se os dados estiverem disponíveis para as partes no caminho na Internet, algumas dessas partes usarão esses dados. Também é verdade que essas partes no caminho precisam de alguns metadados para facilitar o transporte desses dados. Este equilíbrio é explorado no RFC 8558, que explica como os protocolos devem ser cuidadosamente projetados no que diz respeito ao equilíbrio entre demasiados metadados (mau para a privacidade) e metadados diminutos (mau para as operações).

Num mundo ideal, os protocolos de Internet seriam desenhados com o princípio do menor privilégio. Forneceriam a quantidade mínima de informações necessárias para as partes no caminho (as tubagens) fazerem o trabalho de transportar os dados para o lugar certo, mantendo por defeito tudo o resto confidencial. Os protocolos atuais, incluindo o TLS 1.3 e o QUIC, são passos importantes para este ideal, mas ficam aquém no que toca à privacidade dos metadados.

As comunicações de hoje refletem dois níveis de proteção de metadados: o primeiro envolve limitar a quantidade de metadados disponíveis para outros observadores (como ISPs), sendo que o segundo envolve limitar a quantidade de metadados que os utilizadores partilham com os próprios provedores de serviços.

Os nomes de "host" são um exemplo de metadados que têm de ser protegidos de observadores terceiros, coisa que o DoH e o ECH pretendem fazer. No entanto, não faz sentido ocultar o nome de host do site que está a visitar. Também não faz sentido ocultá-lo de um serviço de diretórios como o DNS. Um servidor de DNS precisa de saber qual é o nome de host que o utilizador está a tentar resolver para o poder resolver por ele!

Quando um provedor de serviços tem conhecimento sobre os sites que o utilizador está a visitar e quem ele é, deparamo-nos com um problema de privacidade. Os sites individuais não têm esta combinação arriscada de informações (exceto no caso de cookies de terceiros, que vão desaparecer em breve dos navegadores), mas os provedores de DNS têm. Felizmente, não é realmente necessário que um resolvedor de DNS conheça tanto o nome do host do serviço para onde vai e de que IP vem. Destrinçar os dois,que é o objetivo do OdoH,é bom para a privacidade.

As estradas devem ser bem alcatroadas, bem iluminadas, ter sinalização correta e estar idealmente interligadas. Não foram concebidas para parar um carro de acordo com quem está lá dentro. Nem devem ser! Como a infraestrutura de transporte, é da responsabilidade da infraestrutura da Internet levar os dados onde eles precisam de chegar, sem, no entanto, olhar para dentro dos pacotes e fazer julgamentos. Mas a Internet é feita de computadores e de software, e o software tem tendência a ser escrito para tomar decisões com base nos dados que lhe estão disponíveis.

Os protocolos de salvaguarda de privacidade tentam eliminar a tentação dos provedores de infraestrutura espreitarem e tomarem decisões baseadas nos dados pessoais que veem. Um protocolo que não salvaguarda a privacidade, como o HTTP, guarda dados pessoais e metadados, como palavras-chave, endereços de IP e nomes de host como partes explícitas dos dados enviados pela rede. O facto de serem explícitos significa que ficam disponíveis para qualquer observador os recolher e agir baseado neles. Um protocolo como o HTTPS melhora isto, tornando alguns dos dados (como palavras-chave e conteúdo do site) invisíveis na rede usando encriptação.

Os três protocolos que estamos a explorar hoje são uma extensão desse conceito.

• O ECH pega na maioria dos metadados não encriptados no TLS (incluindo o nome de host) e encripta-os com uma chave que foi apanhada antecipadamente.

• O ODoH (uma nova variante do DoH co-projetada pelos engenheiros da Apple e da Cloudflare) usa proxies e encriptação do tipo "cebola" para tornar a origem de uma consulta de DNS invisível aos olhos do resolvedor de DNS. Isto protege o endereço de IP do utilizador ao resolver nomes de host.

• O OPAQUE usa uma nova técnica criptográfica para manter as palavras-passe ocultas até mesmo do servidor. Ao usar uma construção chamada Oblivious Pseudo-Random Function - Função Pseudo-Aleatória Alheia - (como visto em Privacy Pass), o servidor não conhece a palavra-passe, só fica a saber se o utilizador a conhece ou não.

Ao garantir que a infraestrutura da Internet age cada vez mais como uma infraestrutura física, a privacidade do utilizador é protegida com maior facilidade. A Internet é mais privada se os dados privados só puderem ser recolhidos quando o utilizador tiver a oportunidade de consentir na sua recolha.

Por mais que estejamos entusiasmados em trabalhar em novas formas de tornar a Internet mais privada, a inovação à escala global não acontece sozinha. Cada um destes projetos resulta do trabalho de um grupo colaborativo de indivíduos, que trabalham de forma aberta em organizações como o IETF e o IRTF. É crucial que os protocolos surjam através de um processo de consenso, envolvendo todas as partes que compõem o conjunto interligado de sistemas que alimentam a Internet. Desde construtores de navegadores, criptógrafos até operadores de DNS e administradores de sites, este é verdadeiramente um esforço de equipa global.

Também reconhecemos que mudanças técnicas abrangentes na Internet inevitavelmente terão impacto além da comunidade técnica. A adoção destes novos protocolos poderá ter implicações legais e políticas. Estamos a trabalhar ativamente com governos e grupos da sociedade civil para ajudar a educá-los sobre o impacto dessas possíveis mudanças.

Estamos ansiosos por partilhar o nosso trabalho hoje, esperando que mais partes interessadas se juntem ao desenvolvimento destes protocolos. Os projetos que estamos a anunciar hoje foram concebido por especialistas académicos, da indústria e por autodidatas, tendo sido construídos por engenheiros da Cloudflare Research (incluindo o trabalho de estagiários, que destacaremos) com o apoio de todos na Cloudflare.

Se está interessado neste tipo de trabalho, estamos a contratar!

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.