Esta é a jornada de 13 anos que resultou no Neulock , uma abordagem diferente para gerenciamento de senhas. Aqui vai articles[0] de articles.length == 2.
Foi em 2011. Contágio ainda era material de filme; as pessoas se comunicavam usando rostos de rabiscos monocromáticos em vez de Pepe, o sapo e doges Shiba Inu, e Daenerys Targaryen foi a garotinha que fez o bárbaro Khal Drogo encontrar o amor.
Foi então que o Google Chrome fez essa oferta pela primeira vez.
Deseja que o Google Chrome salve sua senha deste site?
Salvar esta senha? Isso é algo que os navegadores fazem agora? Uau, obrigado, Chrome, isso é muito conveniente! Pensando bem, eu digito a maioria das senhas em um navegador da web, então este parece ser um ótimo lugar para salvá-las.
Além disso, qual é a pior coisa que pode acontecer? Chrome é um programa instalado no meu computador. MEU computador! Sou um usuário experiente do Debian Linux e em nenhum lugar do universo existe um lugar mais seguro do que meu disco rígido!
Claro, Chrome, vá em frente. Salve esta senha, a próxima e todas as senhas digitadas em seus campos de entrada.
Até que comprei outro computador. Depois de trocar o Windows pré-instalado por qualquer distribuição Linux que eu gostasse na época, a próxima coisa a fazer foi instalar o Chrome. Ainda faltavam seis anos para o Firefox Quantum, então não havia muita escolha.
Entre com sua conta do Google? Claro, por que não? Vamos dar uma olhada no Facebook ou algo assim e… ei, você se lembra do meu nome de usuário, Chrome? Tudo bem, vamos entrar no Facebook. Espere, por que o campo de senha já está preenchido com asteriscos? Não, querido Chrome, deve ser um bug, acabei de comprar este computador, seu banco de dados local está impecável. Você perceberá seu erro quando eu clicar no botão de login. E… estou dentro?
Fui verificar as configurações do Chrome imediatamente. O que vi só aumentou meu horror. Todos os sites e nomes de usuário que eu salvei estavam lá, em uma lista. As senhas em texto simples estavam a apenas um clique de distância.
Duas expectativas foram quebradas. A primeira e mais importante é que nunca esperei que o Chrome carregasse minhas senhas para os servidores do Google sem pedir consentimento. Eles me pediram para salvar minhas senhas, não para compartilhá-las!
A segunda expectativa era uma ilusão da minha parte. Que vergonha. O Google é uma das empresas de tecnologia mais legais do mundo, e seus engenheiros são considerados gênios fazendo o impossível entre partidas de pingue-pongue no Googleplex. Achei que o Chrome estava armazenando minhas senhas de uma forma supersegura e apenas recuperando cada senha no momento certo para injetá-la como um ninja no campo de entrada preciso ao qual ela pertencia. Eu não esperava ver todos eles em texto simples.
E eu não fui o único que ficou chocado. Elliott Kember chamou a segurança das senhas do Chrome de “insana ”. Em uma discussão mais aprofundada, Justin Schuh, chefe de segurança do Chrome, apenas deu de ombros de uma maneira bastante arrogante. Sir Tim Berners-Lee ficou do lado de Kember, chamando o gerenciador de senhas do Chrome de “ uma maneira de obter as senhas da sua irmã mais velha ”.
Depois dessa experiência, nunca mais consegui confiar em nenhum gerenciador de senhas, mesmo sabendo que era melhor do que confabular senhas estranhas na minha estúpida cabeça humana. Mas, como dizemos no Brasil, um cachorro que foi picado por uma cobra tem medo até de salsicha. Não faz mais sentido em português.
Passei os dez anos seguintes vagando pelo deserto da insegurança de senhas. Eu ansiava por um gerenciador de senhas melhor, mas todos pareciam seguir o mesmo princípio: agrupar todas as suas senhas em um “cofre”, criptografá-lo com sua chave mestra e carregar esse cofre em seus servidores em nuvem. Eu nunca poderia confiar neste modelo. Eles estão implementando criptografia ponta a ponta, certo? Existe um backdoor de “recuperação de chave” esperando para ser explorado? Ou talvez Justin Schuh estivesse certo, afinal: suas senhas são “recuperadas trivialmente” de qualquer aplicativo que as armazene, e as tentativas de dificultar o vazamento de senhas são “todas apenas teatro”. Nesse sentido, tentar proteger suas senhas além de confiar em um gerenciador de senhas era uma tarefa tola para novatos.
Em 2019, desembarquei no Departamento de Informática do Ministério das Relações Exteriores do Brasil. Lá, acompanhei o CTO e guru de tecnologia Fabio Cereda . Aprendi muito com ele e assumi depois que ele saiu. A segurança cibernética sempre esteve em pauta, já que aquele Ministério produzia cerca de 80% de todas as informações sigilosas do governo federal brasileiro e suas operações estavam espalhadas por 240 localidades em todos os continentes habitáveis. Éramos constantemente alvo das siglas mais assustadoras do mundo, por isso precisávamos manter a guarda alta o tempo todo. Ao longo desses anos, através da exposição constante a problemas em diferentes domínios da segurança cibernética, comecei a reunir princípios para um melhor gerenciador de senhas.
Havia um museu de comunicações diplomáticas onde trabalhei. Estava cheio de livros de códigos, máquinas de cifragem de ferro fundido, antenas parabólicas portáteis para malas, adaptadores TELEX e alguns exemplares da infame máquina Crypto AG C-52 . Foi uma vitrine de um século e meio de comunicações secretas entre a sede e as embaixadas e missões diplomáticas brasileiras no exterior. Todos eles dependiam de algum tipo de criptografia para guardar os segredos. Toda essa criptografia está quebrada.
Se você pensar em um gerenciador de senhas, o fato de que todas as criptografias acabarão sendo quebradas não é assustador. Digamos que sejam necessários, em média, 15 anos para quebrar um protocolo criptográfico. Basta alterar suas senhas a cada dois anos e você ficará bem. Um gerenciador de senhas decente deve atualizar sua criptografia de vez em quando para que você esteja sempre à frente da curva.
A parte assustadora é que é impossível saber se um protocolo já foi quebrado. Ou pior, se foi projetado com uma vulnerabilidade intencional e oculta, como foi o caso da máquina Crypto AG. Agências de inteligência e organizações cibercriminosas mantêm seus dias zero sob o radar enquanto podem.
Quanto mais eu via sistemas de segurança corporativos de última geração vazando informações secretas, às vezes de maneiras catastroficamente espetaculares, menos eu confiava no modelo de cofre empregado por todos os gerenciadores de senhas baseados em nuvem.
Até muito recentemente, estas preocupações eram meramente teóricas. Como escreveu o colega hackernoon @ hossam26644 ,
Não há nada de errado em usar o gerenciador de senhas do Google, Microsoft, Apple, 1password, Bitwarden ou qualquer outro. As pessoas os usam há muito tempo, sem nenhum problema até agora.
Ele estava certo em 25 de julho de 2022. Porém, ele não confiava em nenhum deles e estava certo novamente. Um ano depois, havia evidências convincentes de que os notórios vazamentos do LastPass estavam resultando na quebra de alguns cofres de alto valor e na perda de dinheiro das pessoas. Mais de 150 pessoas, mais de US$ 35 milhões em dinheiro.
Um equívoco comum é que, para que um cofre criptografado seja quebrado, o próprio algoritmo AES precisaria ser comprometido. O LastPass nos lembrou como é muito mais fácil quebrar a criptografia. O AES se mantém forte, mas o LastPass tomou decisões de implementação ruins: requisitos de chave mestra muito curtos, poucas iterações e alguns usuários ficaram com cofres que eram facilmente quebráveis por força bruta.
Os criptoanalistas do governo conheciam muito bem o Princípio nº 0. Eles são algumas das pessoas mais inteligentes que já conheci, e poucos deles apostariam dinheiro em algo protegido apenas por criptografia.
Os mais cautelosos insistiram no uso de um One-Time Pad (OTP) para comunicações criticamente seguras. Na verdade, colocaram este requisito nos regulamentos para a transmissão e armazenamento de documentos ultrassecretos.
Em princípio, uma cifra OTP não pode ser quebrada. É uma operação XOR simples do texto simples (os dados) e um buffer de valores aleatórios do mesmo comprimento dos dados (a chave OTP). Ao fazer XOR da cifra contra a mesma chave novamente, o texto simples é recuperado.
Embora inquebrável do ponto de vista da criptoanálise, o OTP tem vários inconvenientes:
Para uma organização mundial, fornecer chaves OTP a cada escritório é uma grande operação logística contínua. Pior ainda, é o calcanhar de Aquiles de todo o modelo de segurança! Porque, para que toda a grandiosidade criptográfica do OTP seja verdadeira, você precisa de uma logística perfeita , tanto em trânsito quanto em repouso.
Eve deve interceptar suas chaves OTP enquanto estiver no caminho para o destino? Todas as suas comunicações a partir desse momento estão comprometidas.
Eve deveria invadir fisicamente sua sala segura e roubar sua mídia chave OTP? Todas as suas comunicações a partir desse ponto serão comprometidas, e talvez até as anteriores, se partes usadas da chave não tiverem sido devidamente apagadas da mídia.
Se você implementar chaves OTP como pedaços de 1 GB de bytes aleatórios que são consumidos conforme você envia informações, claramente faltará sigilo direto e retroativo.
No final das contas, a criptografia perfeita é uma forma de transferir a responsabilidade da equipe de segurança cibernética para a equipe de segurança física.
E um problema semelhante afeta os gerenciadores de senhas off-line: eles trocam a disponibilidade pela confidencialidade, deixando você com uma confusão logística para resolver.
Como qualquer pessoa que execute uma cópia local do KeePass sabe, você precisa fazer backup do seu cofre. É melhor que esse backup seja externo, caso o armazenamento do seu computador acabe. Você precisa manter seu backup atualizado. E certifique-se de que ninguém tenha acesso a ele. E não os mantenha todos em sua casa, para que não sejam vítimas de inundações e incêndios. E não faça upload deles para o Google Drive; caso contrário, você não usará mais um gerenciador de senhas offline. E…
Um dia, meu chefe me ligou. Ela queria compartilhar um PDF com dez pessoas do escalão superior. Esta informação deve permanecer em seus olhos apenas por três dias. Ela sabia que eles tinham incentivos para compartilhar este documento com suas respectivas equipes para obter vantagem. Esse tipo de informação deveria ser apresentada pessoalmente, mas cobiçada. Então, ela me pediu para tornar este PDF impossível de copiar e compartilhar.
— Não é possível, respondi.
Meu chefe era um embaixador. Este é o equivalente diplomático de um General. Os embaixadores não estão habituados a ouvir “não” como resposta.
Expliquei pacientemente que, na ciência da computação, quando você dá permissão de leitura a alguém para um recurso, você implicitamente dá permissão para copiar e distribuir. Os direitos de acesso à informação não obedecem aos direitos legais. Mesmo que de alguma forma tornássemos inconveniente o compartilhamento do arquivo, eles poderiam simplesmente tirar fotos de suas telas com seus telefones e compartilhá-las pelo WhatsApp. Se eles conseguem ver o documento na tela, suas câmeras também conseguem.
Justin Schuh estava certo. Se alguém obtiver acesso total ao seu computador (ou telefone), terá acesso total às informações que você, usuário, pode acessar por meio desse dispositivo. Ele está certo, mas isso não o desculpa por implementar um gerenciador de senhas tão ruim no Chrome.
Para um gerenciador de senhas, significa que proteger o dispositivo do usuário é sempre fundamental. Se o servidor vazar, os invasores ainda precisarão enfrentar o desafio de invadir os cofres. Mas se um hacker obtiver propriedade total do computador que executa o cliente gerenciador de senhas, nada o impedirá de roubar todas as senhas.
Isso acontece com bastante frequência na comunidade criptográfica. A usuária Alice possui algumas dezenas de BTC, o que a torna milionária. Ela foi enganada ou nunca escondeu sua identidade. Ela mantém uma cópia de sua frase inicial em um gerenciador de senhas local em seu desktop. “Este não é um gerenciador de senhas na nuvem; Estou a salvo de vazamentos”, pensa ela. Os hackers encontram uma maneira de fazê-la instalar um backdoor em seu computador. Se forem realmente bons, poderão fazer isso sem interação do usuário. Na manhã seguinte, ela acorda com a carteira vazia.
Apesar de toda a tristeza e tristeza sobre o comprometimento dos dispositivos do usuário, há uma fresta de esperança: proteger nossos próprios dispositivos, como usuários, é algo que está sob nosso controle. Um vazamento de servidor não é. As mais de 150 pessoas que perderam milhões com o vazamento do servidor LastPass não assumiram qualquer responsabilidade pelos vazamentos ou pela implementação de padrões de criptografia inadequados pelo LastPass.
Se o comprometimento do dispositivo do usuário for um vetor de ataque catastrófico, independentemente do modelo de segurança do gerenciador de senhas, e se nós, como usuários, precisarmos proteger nossos dispositivos de qualquer maneira, não seria bom se esse fosse o único vetor de ataque? Se pudéssemos construir um gerenciador de senhas on-line onde nenhum segredo deixasse os dispositivos do usuário, para que os usuários não precisassem se preocupar com coisas fora de seu controle, como segurança do servidor e detalhes de implementação do AES?
O colega autor @hossam26644 continuou, em seu artigo : “talvez eu seja um fanático por segurança, mas não quero confiar minhas senhas a uma entidade, independentemente de suas promessas e/reputação”. Ele está certo novamente. A segurança cibernética deve ser comprovada e auditável, e não baseada em confiança e reputação.
Os três princípios descritos acima orientaram meu desenvolvimento do Neulock Password Manager . Levei três anos de idealização e iterações para chegar à sua forma atual: um gerenciador de senhas auditável baseado em nuvem que atinge zero conhecimento por design e não por meio de criptografia. As senhas são sincronizadas entre os dispositivos dos usuários usando a nuvem, mas nenhum segredo sai desses dispositivos. Os comprometimentos do servidor em nuvem não podem vazar nenhum segredo porque os segredos nunca chegam à nuvem.
Os três anos de fabricação do Neulock serão documentados na Parte II.