Criptografia usável: Moxie Marlinspike sobre UX e segurança

Quando sistemas seguros falham: as pessoas contornam-nos

Um sistema pode ser “seguro no papel” e ainda assim ser inseguro na prática. Muitos designs assumem um comportamento perfeito: que toda a gente lê avisos, segue cada passo e não comete erros. Pessoas reais fazem o oposto quando estão ocupadas, stressadas ou a tentar terminar uma tarefa.

Essa lacuna é onde a segurança se desfaz silenciosamente. Se uma mensagem encriptada exige cinco passos confusos para abrir, as pessoas não ficam mais cuidadosas. Procuram um atalho que pareça fiável, mesmo que enfraqueça a proteção.

Esses atalhos parecem inofensivos, mas anulam o propósito da criptografia. Pessoas enviam screenshots em vez de usar um visualizador seguro, colam segredos em notas ou chat “só por um minuto”, reutilizam a mesma palavra‑passe em várias ferramentas, desativam uma funcionalidade que “anda sempre a atrapalhar” ou partilham uma conta porque os controlos de acesso parecem lentos.

Criptografia usável não é ensinar os utilizadores a fazer criptografia. É tornar o caminho seguro o mais fácil, com menos decisões e menos maneiras de ficar preso. Quando as pessoas conseguem completar a tarefa rápida e confiantemente, não precisam de atalhos.

A lição de Moxie Marlinspike: segurança que as pessoas conseguem usar

O trabalho do Moxie Marlinspike aponta para uma verdade simples: a segurança só funciona quando se ajusta ao comportamento humano real. Pessoas estão ocupadas, distraídas e muitas vezes sob pressão. Se um fluxo seguro adiciona atrito, elas encontrarão um caminho mais rápido, mesmo que quebre silenciosamente a proteção que pretendia oferecer.

Por isso, a velha mentalidade de “os utilizadores são o inimigo” gera produtos maus. Trata o comportamento normal como sabotagem. O resultado é um design que recorre a repreensões e punições: regras complexas, popups assustadores e mensagens do tipo “não faça isto”. Essas escolhas treinam as pessoas a clicar sem ler, partilhar palavras‑passe, reutilizar códigos ou desativar funcionalidades. Não se obtêm resultados mais seguros, obtêm‑se falhas silenciosas.

A mensagem encriptada mostra isto sem entrar em tecnicismos. Quando as pessoas tinham de comparar impressões digitais longas, gerir chaves manualmente ou interpretar alertas de segurança ambíguos, muitos ignoravam as verificações. A ferramenta era “segura” no papel, mas a segurança não sobreviveu ao uso diário.

Criptografia usável não é criptografia mais fraca. É criptografia envolvida em fluxos que as pessoas conseguem completar corretamente, todas as vezes.

Na prática, “usável” costuma resumir‑se a quatro traços:

• Compreensível: a app explica o que está a acontecer em palavras simples no momento em que importa.
• Rápida: a escolha segura é também a escolha mais fácil.
• Perdoável: erros pequenos não causam danos irreversíveis.
• Recuperável: se um telefone for perdido ou uma sessão expirar, as pessoas podem recuperar o acesso em segurança sem pânico.

Imagine alguém a trocar de telefone. Se o único caminho de recuperação for “encontre o dispositivo antigo e exporte as chaves”, muitos vão fazer screenshot de códigos, guardar segredos em notas ou recorrer a um canal inseguro. Um design usável espera por esse momento e torna o caminho seguro óbvio.

Porque a usabilidade quebra a criptografia no mundo real

A criptografia normalmente falha nos momentos em que as pessoas a tocam. Não porque não gostem de privacidade, mas porque o “imposto da segurança” aparece quando estão ocupadas, stressadas ou a ajudar outra pessoa.

Os pontos dolorosos são previsíveis: configuração inicial que pede escolhas que o utilizador não entende, fluxos de login que adicionam passos sem explicar porquê, troca de dispositivos com perda súbita de acesso, partilha rápida que esbarra em permissões confusas, e recuperação após perda de dispositivo ou palavra‑passe esquecida.

Quando o atrito é alto, as pessoas fazem o que funciona. Reutilizam palavras‑passe, mantêm sessões sempre logadas, desativam verificações extras ou mudam a conversa “segura” para uma app mais rápida.

A sobrecarga cognitiva é um grande motor. Muitos produtos seguros perguntam coisas como “Qual chave pretende confiar?” ou “Quer encriptação local ou no servidor?” A maioria não tem um modelo mental para isso, então adivinham. Se a UI acrescentar avisos assustadores, a adivinhação vira pânico.

Alguns padrões de aviso quase garantem o contorno:

• Muitas opções sem um padrão claro
• Jargão como “chaves”, “certificados” ou “impressões digitais” sem explicação simples
• Banners vermelhos que soam catastróficos mas não dizem o que fazer a seguir
• Pedidos frequentes que parecem importunos

A pressão do tempo torna tudo pior. Se um código expira enquanto alguém entra numa reunião, escolhem a velocidade em vez da segurança. A pressão social faz o resto: quando um colega diz “Envia já”, a partilha segura torna‑se numa corrida, não num hábito.

Princípios de design para UX de criptografia (simples e práticos)

A segurança falha quando as pessoas sentem‑se forçadas a adivinhar. Um bom UX de criptografia remove a adivinhação tornando o caminho seguro o mais fácil. Se uma escolha segura exige ler uma página de ajuda ou pedir ao TI, muitos escolherão outra coisa.

Comece por reduzir decisões. A maioria das telas deve oferecer uma opção clara e recomendada e uma curta razão para essa recomendação. Configurações avançadas podem existir, mas não devem aparecer no fluxo principal até alguém realmente precisar.

Mostre o risco de forma visível, mas calma. Substitua avisos assustadores por resultados práticos que as pessoas consigam imaginar. “Qualquer pessoa com este link pode ver o ficheiro” é mais útil do que “Partilha pública é insegura.” Pessoas agem com base em consequências, não rótulos.

Projete para erros como caso normal. Numa criptografia usável, a recuperação é parte da segurança, não um extra. Assuma que alguém vai partilhar a coisa errada, perder um dispositivo ou enviar uma mensagem à pessoa errada.

Um pequeno conjunto de princípios resiste em produtos reais:

• Por defeito, escolha o modo mais seguro que ainda funcione para a maioria dos utilizadores.
• Explique ações sensíveis em uma frase, usando palavras do dia a dia.
• Adicione desfazer, revogar acesso e um estado claro como “partilhado com 3 pessoas”.
• Revele detalhes apenas quando o utilizador pedir ou quando o risco realmente mudar.

A divulgação progressiva ajuda a evitar fadiga de “parede de definições”. Mostre só o necessário para terminar o passo atual e adie o resto. Quando o detalhe extra importa, apresente‑o como uma escolha com contexto, não como uma surpresa.

Trate a confusão como uma superfície de ataque. Se o suporte continuar a ouvir “não sei o que isto significa”, as pessoas vão contornar a funcionalidade por email com cópias não encriptadas, screenshots ou reutilizando palavras‑passe fracas. A correção mais rápida costuma ser não mais avisos, mas um fluxo mais simples e padrões seguros.

Padrões de autenticação que as pessoas não vão resistir

Muitos sistemas “seguros” falham à porta. Se iniciar sessão é sofrido, as pessoas reutilizam palavras‑passe fracas, desativam proteções ou procuram o atalho mais rápido. Para criptografia usável, a autenticação tem de ser difícil de quebrar e fácil de conviver.

Remova palavras‑passe onde puder. Passkeys e outras opções sem palavra‑passe frequentemente reduzem o risco de phishing e diminuem o suporte a credenciais esquecidas. Ainda assim, precisa de uma alternativa para os momentos em que o caminho fácil falha (dispositivo novo, telemóvel perdido, conta bloqueada). Essa alternativa deve ser compreensível, não um labirinto de perguntas de segurança.

As sessões devem ser curtas o suficiente para limitar danos, mas não tão curtas que os utilizadores tenham de iniciar sessão a cada hora. Um bom meio‑termo é uma sessão normal para trabalho rotineiro, mais reautenticação silenciosa para ações sensíveis. Usuários aceitam reautenticação quando está ligada a uma razão clara.

Use step‑up authentication para ações que mudam a história de segurança, como exportar dados ou código‑fonte, convidar novos membros, alterar permissões de partilha, editar definições de admin (faturação, papéis, métodos de recuperação), adicionar um novo dispositivo ou aprovar deployments e alterações de domínio.

A autenticação em dois fatores pode ser eficaz sem se transformar numa punição diária. Deixe as pessoas marcar dispositivos confiáveis e peça novamente só quando o risco mudar (localização nova, browser novo, comportamento invulgar). Se tiver de desafiar frequentemente, mantenha o desafio rápido.

Evite mudanças forçadas de palavra‑passe por calendário. Elas treinam padrões previsíveis e o armazenamento inseguro de palavras‑passe. Invista em deteção de comprometimento e recuperação: notifique em novos inícios de sessão, mostre sessões ativas e permita revogar acesso num só lugar.

Numa plataforma como o Koder.ai, isso pode significar manter o login rápido para trabalho normal, mas exigir reautenticação quando alguém exporta código‑fonte, altera um domínio customizado ou edita papéis de equipa — momentos em que uma sessão roubada pode causar dano real.

Gestão de chaves que não parece uma armadilha

Uma boa gestão de chaves tem três objetivos que os utilizadores conseguem entender: manter os dados privados, permitir que as pessoas certas acedam e garantir que é possível recuperar o acesso quando algo corre mal. Se qualquer um desses pontos parecer frágil, as pessoas inventarão o seu próprio atalho, como guardar segredos em notas ou partilhar screenshots.

Para a maioria dos utilizadores, as chaves devem ser geridas automaticamente. O produto pode gerar chaves, guardá‑las no armazenamento seguro do dispositivo e rodá‑las quando necessário. Não se deve pedir ao utilizador para copiar cadeias longas, nomear ficheiros ou escolher entre formatos confusos.

Utilizadores avançados e equipas por vezes precisam de controlo, por isso é razoável oferecer um caminho “avançado” para exportação ou chaves geridas por admin. A chave é não forçar toda a gente a esse modo.

As trocas de dispositivo são onde a confiança se parte. Torne o resultado previsível antes de acontecer. Se um telefone for perdido, o utilizador deve saber desde já se a recuperação é possível, o que vai precisar e o que será perdido permanentemente. Não esconda isso atrás de um aviso assustador depois do facto.

Um modelo mental útil é: iniciar sessão prova quem você é, desencriptar desbloqueia os dados. Pode manter as telas simples, mas não implique que uma palavra‑passe sozinha possa sempre restaurar tudo. Se a desencriptação depende de uma segunda coisa (como um dispositivo confiável ou um código de recuperação), diga‑o claramente.

Use nomes que as pessoas reconheçam e mantenha‑os consistentes. “Código de recuperação”, “dispositivo confiável” e “dispositivo perdido” são mais claros do que uma mistura de termos técnicos que mudam de ecrã para ecrã.

Exemplo: alguém troca de telemóvel. Depois de iniciar sessão, vê “Aprovar num dispositivo confiável” ou “Usar código de recuperação”. Se não tiver nenhum, a app diz: “Podemos reiniciar a sua conta, mas os dados encriptados antigos não poderão ser recuperados.” A verdade clara previne atalhos arriscados.

Padrões de partilha segura que não dependem de avisos

A partilha é onde a boa segurança frequentemente perde. Se a opção segura parecer lenta ou confusa, as pessoas enviam screenshots, reencaminham ficheiros para emails pessoais ou colam segredos no chat. Criptografia usável significa que o fluxo de partilha é seguro por defeito, não um popup assustador.

Comece por um fluxo de convite, não por um link cru. Um convite pode estar ligado a uma pessoa ou equipa, com papéis claros e data de validade. Mantenha as escolhas simples e concretas: “Pode ver”, “Pode editar” e “Pode gerir acesso”. Limites temporais devem ser normais para itens sensíveis, como acesso de contractors que expira ao fim de uma semana.

Torne a revogação rápida e óbvia. Coloque o acesso num só lugar, com uma ação única para remover alguém, rodar chaves se necessário e invalidar sessões antigas. Se as pessoas tiverem de procurar nas definições, vão evitar a partilha segura da próxima vez.

A clareza vence os avisos. Use rótulos simples que batam com a intenção: partilhar com uma conta para acesso contínuo, partilhar com um dispositivo específico para uma pessoa numa máquina, e partilhar por link só quando realmente necessário.

Adicione guardrails para ações arriscadas sem ser importuno. Se partilhando fora da organização, exija um motivo e limite temporal. Para links públicos, mostre uma pré‑visualização do que fica público. Para exportações, mostre o que está incluído (dados, segredos, histórico) e ofereça uma alternativa mais segura.

Finalmente, mostre um histórico de atividade que as pessoas consigam ler: “Ava abriu”, “Ben alterou permissões”, “Link público criado”, com quem, o quê e quando. Se construir apps no Koder.ai, a mesma ideia aplica‑se a partilha de deployments, exportações de código ou snapshots: torne o acesso visível, limitado no tempo e fácil de reverter.

Passo a passo: desenhar um fluxo seguro e usável

Escreva a jornada do utilizador como uma história simples, não como um diagrama. Inclua os momentos que normalmente quebram a segurança: registo, a primeira vez que alguém partilha algo sensível, adicionar um novo dispositivo e o que acontece após perda de telefone ou portátil. Se não conseguir explicar cada momento em uma ou duas frases, os utilizadores também não conseguirão.

Depois procure pontos de bypass: onde uma pessoa normal vai apanhar um atalho porque o caminho seguro parece lento ou confuso. Screenshots de códigos “temporários”, copiar segredos para notas, reutilizar uma palavra‑passe em todo lado ou enviar um ficheiro fora da app “só desta vez” são sinais. Trate os bypasses como feedback sobre o design, não como falha do utilizador.

Uma ordem prática para construir:

• Defina padrões seguros primeiro: partilha com menor privilégio, timeouts de sessão sensatos e o menor número de passos que ainda protejam os dados.
• Escreva o fluxo em microcopy de linguagem simples antes do polimento da UI. Se precisar de jargão como “certificados”, reescreva.
• Prototipe o caminho completo, incluindo casos de canto (dispositivo novo, offline, rede fraca).
• Adicione caminhos de recuperação cedo: troca de dispositivo, recuperação de conta e desfazer onde importa.

Recuperação e rollback merecem atenção extra porque decidem se as pessoas confiam no sistema. Fluxos de “sem volta” empurram os utilizadores para gambiarras inseguras. Se uma partilha foi enviada à pessoa errada, pode ser revogada? Se um dispositivo for perdido, é possível cortar o acesso sem bloquear o proprietário real por dias?

Se o seu produto suporta snapshots e rollback (como o Koder.ai faz), aplique a mesma mentalidade às ações de segurança: torne passos irreversíveis raros e claramente rotulados, e facilite o “desfazer” quando for seguro fazê‑lo.

Por fim, teste com utilizadores não técnicos e observe onde ficam presos. Não pergunte “Faria isto?”; dê‑lhes um objetivo e fique em silêncio.

Procure onde hesitam, relêem texto, mudam de app (notas, câmara, email), adivinham e erram ou abandonam o caminho seguro. Registe esses momentos, corrija o fluxo e teste novamente.

Armadilhas comuns de UX que fazem os utilizadores contornar a segurança

A segurança falha mais frequentemente quando o caminho seguro parece confuso, lento ou arriscado. As pessoas não acordam a querer violar a política. Querem apenas terminar a tarefa, e escolhem a opção que parece certa.

Armadilhas comuns que empurram para gambiarras inseguras:

• Popups assustadores e avisos técnicos: Se toda ação dispara um modal sobre certificados, impressões digitais ou “chaves não verificadas”, os utilizadores aprendem uma coisa: clicar para continuar.
• Recuperação escondida até ao desastre: Se “configurar recuperação” só aparece depois de perder o dispositivo, já é tarde demais.
• Identidade misturada com dispositivos: Pessoas entendem “isto é o João”. Têm dificuldade com “isto é a chave do dispositivo do João de há 14 dias”.
• Partilha segura mais lenta que partilha insegura: Se enviar um ficheiro encriptado leva cinco passos e partilhar sem encriptar um passo, o caminho de um passo vence sob pressão.
• Muitas definições, sem padrão seguro: Uma página longa de definições convida ao “trial and error”. Utilizadores alternam opções até os avisos desaparecerem.

Um exemplo simples: um gestor precisa de partilhar um contrato com um novo contractor durante uma reunião. Se adicionar o contractor exige escanear códigos, comparar cadeias longas e ler um aviso sobre “identidade desconhecida”, é provável que mande o ficheiro por email ou o cole no chat. A ferramenta não perdeu porque a criptografia era fraca. Perdeu porque pareceu pouco fiável.

A solução normalmente não é mais educação. É um caminho claro e rápido que seja seguro por defeito, com recuperação e decisões de confiança mostradas cedo, em linguagem simples.

Lista rápida de verificação para UX de criptografia usável

Trate a criptografia usável como um fluxo de checkout: cronometre, observe pessoas a fazê‑lo e assuma que irão saltar qualquer coisa que pareça confusa.

Configuração e recuperação

Um novo utilizador deve concluir a configuração segura em menos de dois minutos sem ler docs ou procurar opções escondidas. Se o seu fluxo depende de “guarde este código em segurança” sem ajuda, espere que as pessoas façam screenshot, percam ou ignorem.

Trocar de dispositivos não deve provocar pânico. Explique claramente o que vai acontecer antes de confirmarem: que dados se movem, o que não se move e como desfazer. Evite surpresas do tipo “isto nunca poderá ser recuperado”.

Controlo e partilha

Antes de lançar, verifique alguns básicos:

• Os utilizadores conseguem ver todas as sessões e dispositivos ativos numa única tela, com nomes claros e hora do último uso?
• Podem revogar um dispositivo ou sessão com uma ação, e isso pára realmente o acesso de imediato?
• Conseguem partilhar com pessoas ou papéis específicos e depois mudar de ideias?
• Exportações sensíveis exigem step‑up (palavra‑passe, biometria ou equivalente)?

Após exportações, deixe um registo claro no histórico de atividade: o quê foi exportado, quando e de que dispositivo. Isto não é para apontar dedos. Ajuda a apanhar erros rapidamente e constrói confiança.

Leia as suas mensagens de erro em voz alta. Se contiverem jargão como “chave inválida” ou “handshake falhou”, reescreva para ação: o que aconteceu, o que isso significa para o utilizador e qual o próximo passo seguro.

Exemplo: uma equipa que precisa de segurança e também de velocidade

Uma agência de três pessoas trata contratos de clientes e ficheiros de design. Trabalham em portáteis em casa e em telemóveis em deslocação. Também precisam de uma forma simples de se coordenarem quando um cliente pede alterações à noite.

Experimentam uma configuração “segura” que é boa no papel mas lenta na prática. Toda a gente tem de digitar uma palavra‑passe longa constantemente, a app desloga com frequência e partilhar uma pasta exige copiar uma string de chave de um dispositivo para outro. Ao fim de uma semana, aparecem as gambiarras: uma palavra‑passe é reutilizada em todo lado, uma conta partilhada é criada “para não ficarmos sem acesso” e conteúdo sensível acaba em screenshots porque é mais rápido do que exportar e re‑encriptar um ficheiro.

Agora reescreva o mesmo fluxo com criptografia usável em mente.

Alice convida Ben e Priya por identidade, com um nome claro de equipa e cliente. Cada um aceita num dispositivo confiável. Os papéis são claros por defeito: Priya é contractor com acesso limitado, Ben é membro, Alice é admin. Dispositivos confiáveis reduzem logins constantes, e reautenticação ocorre apenas para ações de alto risco como adicionar um dispositivo, exportar dados ou alterar recuperação.

A recuperação encaixa na vida real: cada membro guarda um código de recuperação uma vez durante a configuração, com linguagem simples sobre quando será necessário. A partilha mantém‑se rápida: “Partilhar com cliente” cria um espaço separado com rótulos claros e opções de expiração.

Um mês depois, Priya sai. Alice remove o acesso dela. O sistema revoga a confiança do dispositivo, termina sessões ativas e re‑encripta os espaços do cliente que Priya podia ler. Ben e Alice recebem uma confirmação curta com carimbos de hora para não ficarem na dúvida se funcionou.

Pequenos detalhes evitam atalhos: nomes que correspondem à forma como as pessoas falam (“Acme - Contratos”), padrões seguros por defeito (acesso mínimo primeiro) e temporização que evita interrupções (configurar uma vez, e depois sair do caminho).

Próximos passos: construir, testar e iterar sem quebrar a confiança

Escolha um fluxo de alto risco e corrija‑o de ponta a ponta. Login, partilha e recuperação de conta são onde as pessoas se bloqueiam e onde são mais propensas a colar segredos em notas, reutilizar palavras‑passe ou desativar proteções só para terminar a tarefa.

Meça onde está a dor, não onde pensa que está. Registe passos repetidos, pontos de abandono e momentos em que abrem ajuda ou contactam suporte. Esses são os hotspots de bypass.

Depois reescreva as palavras no ecrã para que correspondam ao objetivo do utilizador. Boa microcopy explica o que a pessoa quer fazer, não como a criptografia funciona. “Confirme que é realmente você para manter a sua conta segura” é mais claro que “Verifique a sua chave”.

Um ciclo que funciona:

• Redesenhe um fluxo por completo (telas, erros, recuperação) antes de passar ao próximo.
• Instrua o atrito: repetições, desistências, pausas longas e pedidos de suporte.
• Substitua avisos por orientação: uma escolha clara, uma consequência clara.
• Teste com 5 a 7 utilizadores não técnicos e observe o que fazem.

Se está a construir uma app e quer prototipar rapidamente estes fluxos, o Koder.ai pode ajudar a iterar autenticação e partilha no modo de planeamento, e depois confiar em snapshots e rollback enquanto testa um UX mais seguro com utilizadores reais.