Recentemente, eu tive tempo para pensar novamente sobre como deve funcionar a função de redefinição segura de senhas, primeiro quando eu implementei essa funcionalidade no , e depois quando ajudei a fazer algo semelhante para outra pessoa. No segundo caso, eu queria dar a ele um link para um recurso canônico com todos os detalhes sobre a implementação segura da função de redefinição. No entanto, o problema é que tal recurso não existe, pelo menos nenhum que descreva tudo o que considero importante. Por isso, decidi escrevê-lo eu mesmo.
Veja, o mundo das senhas esquecidas é, na verdade, bastante enigmático. Existem muitas perspectivas diferentes e totalmente aceitáveis, além de uma série de pontos de vista bastante arriscados. Há uma boa chance de que você já tenha encontrado muitas delas como usuário final; por isso, tentarei usar esses exemplos para mostrar quem faz tudo certo e quem não faz, e em que devemos nos concentrar para implementar a função corretamente em nosso aplicativo.
Armazenamento de senhas: hashing, criptografia e (oh!) texto simples
Não podemos discutir o que fazer com senhas esquecidas sem antes discutir a forma como elas são armazenadas. No banco de dados, as senhas são armazenadas de uma das três maneiras principais:
- Texto simples. Há uma coluna com a senha armazenada em texto comum.
- Criptografada. Normalmente, usando criptografia simétrica (uma chave é usada tanto para criptografar quanto para descriptografar), e senhas criptografadas também são armazenadas em uma única coluna.
- Hashed. Um processo unidirecional (uma senha pode ser hashed, mas não pode ser desfeita); a senha, espera-se, é acompanhada de um sal, e cada um deles está em sua própria coluna.
Vamos abordar imediatamente a questão mais simples: nunca armazene senhas em texto simples! Nunca. Uma única vulnerabilidade , um backup feito descuidadamente ou um dos muitos outros erros simples — e pronto, game over, todas as suas senhas — ou melhor, as senhas de todos os seus clientes se tornarão de domínio público. É claro que isso significará uma grande probabilidade de que se tornem de domínio público de todas as suas contas em outros sistemas. E isso será culpa sua.
A criptografia é melhor, mas tem suas fraquezas. O problema da criptografia está na descriptografia; é possível pegar esses códigos que parecem insanos e transformá-los de volta em texto simples, e quando isso acontece, voltamos à situação das senhas legíveis. Como isso acontece? Um pequeno erro infiltra-se no código responsável pela descriptografia da senha, tornando-a publicamente acessível — essa é uma das maneiras. Hackers obtêm acesso à máquina onde os dados criptografados estão armazenados — essa é a segunda maneira. Outra maneira é que uma cópia de segurança do banco de dados é roubada, e alguém também obtém a chave de criptografia, que muitas vezes é armazenada de forma bastante insegura.
E isso nos leva à hashificação. A ideia da hashificação é que ela é feita em uma única direção; a única maneira de comparar a senha digitada pelo usuário com sua versão hashificada é fazer a hashificação da entrada e comparar. Para prevenir ataques utilizando ferramentas como ‘tabelas arco-íris’, adicionamos aleatoriedade ao processo com o uso de um sal (para uma visão mais completa, leia meu sobre armazenamento criptográfico). No final das contas, com a implementação correta, podemos ter uma grande confiança de que as senhas hashificadas nunca se tornarão texto simples novamente (sobre as vantagens de diferentes algoritmos de hash, falarei em outro post).
Um resumo sobre hashificação e criptografia: a única razão pela qual você precisaria criptografar uma senha e não hashificá-la é quando você precisa ver a senha em texto simples, e você nunca deve querer isso, pelo menos, em um cenário de site padrão. Se você precisa disso, é provável que esteja fazendo algo errado!
Atenção!
Um pouco mais abaixo no texto do post, há uma parte de um screenshot de um site pornográfico chamado AlotPorn. Ele foi cuidadosamente cortado e não há nada lá que você não possa ver na praia, mas se isso ainda pode causar problemas, não role para baixo.
Sempre redefina a senha, nunca a lembre
Você já foi solicitado a criar uma função de lembrança senha? Dê um passo atrás e pense sobre esse pedido de forma reversa: por que precisamos desse "lembrete"? Porque o usuário esqueceu a senha. O que realmente queremos fazer? Ajudá-lo a entrar no sistema novamente.
Eu entendo que a palavra "lembrete" é usada (frequentemente) de forma coloquial, mas na verdade estamos tentando ajudar o usuário a voltar online com segurança. Como precisamos de segurança, há duas razões pelas quais o lembrete (ou seja, enviar a senha do usuário) não é adequado:
- O e-mail é um canal inseguro. Assim como não enviaríamos nada confidencial por HTTP (usaríamos HTTPS), não devemos enviar nada por e-mail, pois sua camada de transporte é insegura. Na verdade, isso é muito pior do que simplesmente transmitir informações por um protocolo de transporte não seguro, porque o e-mail muitas vezes é armazenado em dispositivos, acessível a administradores de sistema, reencaminhado e disseminado, acessível a malware, e assim por diante. E-mail não criptografado é um canal extremamente inseguro.
- Você de qualquer forma não deveria ter acesso à senha. Leia novamente a seção anterior sobre armazenamento — você deve ter um hash da senha (com uma boa sal robusta), ou seja, de forma alguma você deve ser capaz de extrair a senha e enviá-la por e-mail.
Deixe-me demonstrar o problema com o exemplo : Aqui está uma página típica de login:
Obviamente, o primeiro problema é que a página de login não é carregada via HTTPS, mas o site também oferece enviar a senha ("Enviar Senha"). Pode ser um exemplo do uso coloquial mencionado acima, então vamos dar mais um passo e ver o que acontece:
Infelizmente, não parece muito melhor; e o e-mail confirma a existência do problema:
Isso nos diz duas aspectos importantes sobre usoutdoor.com:
- O site não faz hash de senhas. Na melhor das hipóteses, elas são criptografadas, mas é bastante provável que estejam armazenadas em texto claro; não vemos evidências do contrário.
- O site envia uma senha permanente (podemos voltar e usá-la repetidamente) por um canal inseguro.
Depois de resolver isso, precisamos verificar se o processo de redefinição está sendo realizado de forma segura. Primeiro, devemos garantir que o solicitante tenha a permissão para executar a redefinição. Em outras palavras, antes disso, precisamos de uma verificação de identidade; vamos ver o que acontece quando a identidade é confirmada sem uma verificação prévia se o solicitante realmente é o proprietário da conta.
A lista de nomes de usuários e seu impacto na anonimidade
Esse problema é melhor ilustrado visualmente. Problema:
Viu? Note a mensagem ‘There is no user registered with this email address’ (‘Não há usuário registrado com este endereço de e-mail’). O problema, evidentemente, surge se um site desse tipo confirma a existência de um usuário registrado com esse endereço de e-mail. Bingo - você acabou de descobrir o fetiche pornô do seu marido/chefe/vizinho!
É claro que pornografia é um exemplo canónico da importância da privacidade, no entanto, o perigo de associar uma identidade a um determinado site é muito mais amplo do que a situação potencialmente embaraçosa descrita acima. Um dos perigos é a engenharia social; se um atacante conseguir associar uma pessoa a um serviço, ele terá informações que poderá começar a usar. Por exemplo, ele pode entrar em contato com a pessoa, se passando por um representante do site, e solicitar informações adicionais, tentando realizar .
Práticas como essa também geram o perigo da ‘enumeração de nomes de usuários’, onde é possível verificar a existência de uma coleção inteira de nomes de usuários ou endereços de e-mail em um site através de simples solicitações em grupo e análise das respostas. Você tem uma lista de endereços de e-mail de todos os funcionários e alguns minutos para escrever um script? Então você consegue ver qual é o problema!
Qual é a alternativa? Na verdade, é bastante simples, e está maravilhosamente implementada na :
Aqui, a Entropay não revela nada sobre a existência de um endereço de e-mail em seu sistema para quem não possui esse endereço. Se você possui este endereço não existe no sistema, você receberá um e-mail similar:
Certamente, há situações aceitáveis em que alguém pensa, que se registrou no site, mas isso não é verdade, ou fez isso com outro endereço de e-mail. O exemplo acima lida bem com ambas as situações. Obviamente, se o endereço corresponder, você receberá um e-mail que simplifica a redefinição da senha.
A sutileza da solução escolhida pela Entropay é que a verificação de identidade é realizada por e-mail antes de qualquer verificação online. Alguns sites pedem aos usuários que respondam a uma pergunta secreta (mais detalhes sobre isso abaixo) até sobre como a redefinição pode começar; no entanto, o problema é que é necessário responder à pergunta, fornecendo algum tipo de identificação (e-mail ou nome de usuário), o que torna quase impossível responder de forma intuitiva sem revelar a existência de uma conta de usuário anônima.
Com essa abordagem, há uma pequena redução na usabilidade, pois ao tentar redefinir uma conta que não existe, não há feedback instantâneo. Obviamente, essa é a razão para o envio do e-mail, mas do ponto de vista do usuário final real, se ele inserir o endereço errado, descobrirá isso apenas ao receber o e-mail. Isso pode causar certo estresse da parte dele, mas é um pequeno preço a pagar por um processo tão raro.
Outra observação, um pouco fora do tópico: as funções de ajuda ao login que revelam a correção do nome de usuário ou endereço de e-mail têm o mesmo problema. Sempre responda ao usuário com a mensagem "A combinação de nome de usuário e senha está inválida" (Your username and password combination is invalid), e não confirme explicitamente a existência de informações de identidade (por exemplo, "o nome de usuário está correto, mas a senha está incorreta").
Envio de senha de redefinição versus envio de URL de redefinição
O próximo conceito que precisamos discutir está relacionado ao método de redefinição de senha. Existem duas soluções populares:
- Geração de uma nova senha no servidor e seu envio por e-mail
- Envio de um e-mail com um URL exclusivo que facilita o processo de redefinição
Apesar de , o primeiro ponto jamais deve ser utilizado. O problema é que isso implica em ter uma senha armazenada, que pode ser acessada e reutilizada a qualquer momento; ela foi transmitida por um canal não seguro e permanece na sua caixa de entrada. Existe a possibilidade de que a caixa de entrada esteja sincronizada com dispositivos móveis e clientes de e-mail, além de poder ser armazenada online em serviços de e-mail por muito tempo. A questão é que a caixa de correio não pode ser considerada um meio seguro de armazenamento a longo prazo.
Mas além disso, o primeiro ponto possui outro sério problema — ele simplifica ao máximo a possibilidade de bloquear a conta maliciosamente. Se eu souber o endereço de e-mail da pessoa que possui a conta no site, posso bloqueá-la a qualquer momento, simplesmente redefinindo sua senha; isso é um ataque do tipo 'negação de serviço', servido em uma bandeja de prata! É por isso que a redefinição deve ser realizada somente após a verificação bem-sucedida dos direitos do solicitante.
Quando falamos sobre a URL de redefinição, referimo-nos ao endereço do site, que é único para este caso específico do processo de redefinição. Evidentemente, ela deve ser aleatória, não deve ser fácil de decifrar e não deve conter links externos para a conta que facilitem a redefinição. Por exemplo, a URL de redefinição não deve ser simplesmente um caminho como 'Reset/?username=JohnSmith'.
Queremos criar um token único que possa ser enviado por e-mail como URL de redefinição e, em seguida, compará-lo com o registro no servidor associado à conta do usuário, confirmando assim que o proprietário da conta é realmente a mesma pessoa que está tentando redefinir a senha. Por exemplo, o token pode ter o formato '3ce7854015cd38c862cb9e14a1ae552b' e ser armazenado em uma tabela junto com o ID do usuário que está fazendo a redefinição e o horário de geração do token (mais detalhes sobre isso um pouco mais adiante). Ao enviar o e-mail, ele contém uma URL como 'Reset/?id=3ce7854015cd38c862cb9e14a1ae552b', e quando o usuário a carrega, a página solicita a existência do token, confirma as informações do usuário e permite a alteração da senha.
Certamente, uma vez que o processo descrito acima (espero) permite que o usuário crie uma nova senha, é necessário garantir que a URL seja carregada via HTTPS. Não, , essa URL com o token deve utilizar a segurança da camada de transporte para que o formulário de entrada da nova senha não possa ser atacado e a senha criada pelo usuário seja transmitida por uma conexão segura.
Além disso, para a URL de redefinição, é necessário adicionar um limite de tempo ao token, para que o processo de redefinição possa ser executado dentro de um intervalo específico, digamos, dentro de uma hora. Isso garante que a janela de tempo de redefinição será mínima, para que quem receber essa URL de redefinição possa agir apenas dentro dessa janela muito pequena. Certamente, um invasor pode reiniciar o processo de redefinição, mas precisará obter outra URL de redefinição exclusiva.
Finalmente, precisamos garantir que esse processo seja de uso único. Após a conclusão do processo de redefinição, o token deve ser removido, de modo que a URL de redefinição não funcione mais. O ponto anterior é necessário para que o invasor tenha uma janela muito pequena na qual pode manipular a URL de redefinição. Além disso, é claro, após a conclusão bem-sucedida da redefinição, o token não é mais necessário.
Alguns desses passos podem parecer excessivos, mas não atrapalham a usabilidade e na verdade aumentam a segurança, embora em situações que, esperamos, sejam raras. Em 99% das vezes, o usuário utilizará a redefinição dentro de um intervalo muito curto e não redefinirá a senha novamente no futuro próximo.
O papel do CAPTCHA
Ah, CAPTCHA, a ferramenta de proteção que todos nós amamos odiar! Na verdade, o CAPTCHA é mais um meio de identificação do que de proteção — você é humano ou um robô (ou um script automatizado). Seu objetivo é evitar o envio automático de formulários, que, naturalmente, pode pode ocorrer como uma tentativa de violar a proteção. No contexto da redefinição de senhas, o CAPTCHA significa que a função de redefinição não pode ser comprometida por força bruta, para depois enviar spam ao usuário ou tentar descobrir a existência de contas (o que, naturalmente, será impossível se você seguiu os conselhos da seção sobre verificação de identidade).
Claro, a própria CAPTCHA não é perfeita; existem muitos casos de "hacking" de seu sistema e conquistas de taxas de sucesso suficientes (60-70%). Além disso, há uma solução mostrada no meu post sobre , onde é possível pagar às pessoas centavos para resolver cada CAPTCHA e obter uma taxa de sucesso de 94%. Ou seja, ela é vulnerável, porém (ligeiramente) eleva a barreira de entrada.
Vamos dar uma olhada no exemplo do PayPal:
Neste caso, o processo de redefinição não pode simplesmente começar até que a CAPTCHA seja resolvida, portanto, teoricamente automatizar o processo é impossível. Teoricamente.
No entanto, para a maioria dos aplicativos web, isso seria um exagero e definitivamente representa uma diminuição na usabilidade — as pessoas simplesmente não gostam de CAPTCHA! Além disso, a CAPTCHA é algo que, se necessário, pode ser facilmente reintroduzido. Se o serviço começar a ser atacado (aqui a gravação de logs é útil, mas falaremos mais sobre isso depois), adicionar CAPTCHA é muito fácil.
Perguntas e respostas secretas
Em todos os métodos que discutimos, tivemos a oportunidade de redefinir a senha apenas tendo acesso à conta de e-mail. Eu digo "apenas", mas, claro, obter acesso ilegal a uma conta de e-mail de outra pessoa deve ser um processo difícil. No entanto, .
Na verdade, o link apresentado acima sobre o hackeamento da conta de Sarah Palin no Yahoo! serve a dois propósitos; em primeiro lugar, ilustra quão fácil é hackear (algumas) contas de e-mail, em segundo lugar, mostra como é possível usar perguntas secretas ruins de forma mal-intencionada. Mas voltaremos a isso mais tarde.
O problema de redefinir senhas com total dependência do e-mail é que a integridade da conta no site cuja senha você está tentando redefinir depende totalmente da integridade da conta de e-mail. Qualquer pessoa que tiver acesso ao seu e-mail, terá acesso a qualquer conta que pode ser redefinida simplesmente recebendo um e-mail. Para essas contas, o e-mail é a "chave para todas as portas" da sua vida online.
Uma das maneiras de reduzir esse risco é implementar o padrão de pergunta e resposta secreta. Sem dúvida, você provavelmente já os viu: você escolhe uma pergunta à qual apenas você deve saber a resposta, e então, ao redefinir a senha, ela é feita. Isso aumenta a confiança de que a pessoa tentando realizar a redefinição é realmente o proprietário da conta.
Voltando a Sarah Palin: o erro estava no fato de que as respostas à sua pergunta/preguntas secretas eram facilmente encontráveis. Em particular, quando você é uma figura pública tão significativa, informações como o sobrenome de solteira da mãe, a história educacional ou onde alguém pode ter vivido no passado não são tão secretas. Na verdade, grande parte pode ser encontrada por praticamente qualquer um. E foi exatamente o que aconteceu com Sarah:
O hacker David Kernell acessou a conta de Palin encontrando detalhes de sua biografia, como sua universidade e data de nascimento, e depois usando a função de recuperação de senhas esquecidas para contas do Yahoo!.
Isso, em primeiro lugar, é um erro de design da parte do Yahoo! — ao permitir perguntas tão simples, a empresa basicamente sabotou o valor da pergunta secreta, e assim, a proteção de seu sistema. Claro, redefinir senhas de uma conta de e-mail sempre é mais complicado, já que você não pode confirmar a posse enviando um e-mail ao proprietário (sem ter um segundo endereço), mas, felizmente, hoje em dia não há tantas maneiras de criar tal sistema.
Voltando às perguntas secretas — há a opção de permitir que o usuário crie suas próprias perguntas. O problema é que isso resultará em perguntas terrivelmente óbvias:
Qual é a cor do céu?
Perguntas que colocam as pessoas em situações constrangedoras, onde para a identificação a pergunta secreta utiliza a pessoa (por exemplo, em um call center):
Com quem eu transei no Natal?
Ou perguntas francamente estúpidas:
Como se escreve 'senha'?
Quando se trata de perguntas secretas, os usuários precisam ser salvos de si mesmos! Em outras palavras, a pergunta secreta deve ser definida pelo próprio site, e ainda melhor, fazer uma série de perguntas secretas, das quais o usuário pode escolher. E não apenas escolher uma; idealmente, o usuário deve escolher duas ou mais perguntas secretas no momento do registro da conta., que serão usados como um segundo canal de identificação. A presença de várias perguntas aumenta a confiança no processo de verificação e também permite a adição de aleatoriedade (não apresentar sempre a mesma pergunta), além de garantir um pouco de redundância caso o verdadeiro usuário tenha esquecido a senha.
Como deve ser uma boa pergunta secreta? Vários fatores influenciam isso:
- Ela deve ser breve — a pergunta deve ser clara e sem ambiguidades.
- A resposta deve ser específica — não queremos uma pergunta que uma pessoa possa responder de maneiras diferentes.
- As possíveis respostas devem ser variadas — uma pergunta sobre a cor favorita de alguém oferece um conjunto de respostas muito pequeno.
- A busca pela resposta deve ser difícil — se qualquer um pode encontrar a resposta facilmente (lembrando das pessoas em posições elevadas), isso é ruim permanente
- A resposta deve ser ao longo do tempo — se perguntarmos qual é o filme favorito de alguém, depois de um ano a resposta pode ser diferente. Como é comum, existe um site dedicado a boas perguntas, chamado
GoodSecurityQuestions.com Deixe-me demonstrar como as perguntas secretas são implementadas no PayPal e, em particular, quais esforços o site faz para identificação. Acima, vimos a página inicial do processo (com CAPTCHA), e aqui mostraremos o que acontece após você inserir o endereço de e-mail e resolver o CAPTCHA:
Como resultado, o usuário recebe um e-mail como este:
Até aqui tudo parece bastante normal, mas aqui está o que está oculto nesse URL de reset:
Então, entram as perguntas secretas. Na verdade, o PayPal também permite redefinir a senha confirmando o número do cartão de crédito, portanto, existe um canal adicional que muitos sites não têm. Eu simplesmente não posso alterar a senha sem responder a
ambas as perguntas secretas (ou sem saber o número do cartão). Mesmo que alguém capture meu e-mail, não poderá redefinir a senha da conta do PayPal, a menos que saiba um pouco mais de informações pessoais sobre mim. Que informações? Aqui estão as opções de perguntas secretas oferecidas pelo PayPal: perguntas secretas (ou não sabendo o número do cartão). Mesmo que alguém consiga acessar meu e-mail, não poderá redefinir a senha da conta do PayPal se não souber um pouco mais de informações pessoais sobre mim. Que tipo de informações? Aqui estão as opções de perguntas secretas oferecidas pelo PayPal:
A questão sobre a escola e o hospital pode ser ligeiramente problemática em termos de facilidade de busca, mas os outros não são tão ruins. No entanto, para aumentar a segurança, o PayPal exige identificação adicional para mudanças responder a perguntas secretas:
O PayPal é um exemplo bastante utópico de recuperação segura de senha: ele implementa CAPTCHA para reduzir o risco de ataques de força bruta, exige duas perguntas secretas e, em seguida, solicita outro tipo completamente diferente de identificação apenas para alterar as respostas - e isso depois que o usuário já fez login. Claro, é exatamente isso que expectávamos do PayPal; é uma organização financeira lidando com grandes somas de dinheiro. Não significa que toda recuperação de senha deva seguir essas etapas - na maioria dos casos isso é excessivo - mas é um bom exemplo para situações em que a segurança é um negócio sério.
A conveniência do sistema de perguntas secretas é que, se você não implementá-lo desde o início, ainda pode adicioná-lo posteriormente, caso o nível de proteção do recurso exija isso. Um bom exemplo disso é a Apple, que recentemente implementou esse mecanismo [artigo escrito em 2012]. Uma vez, ao atualizar um aplicativo no iPad, vi o seguinte pedido:
Então vi uma tela onde eu poderia escolher pares de perguntas e respostas secretas, bem como um endereço de e-mail de recuperação:
No que diz respeito ao PayPal, as perguntas são escolhidas antecipadamente e algumas delas são realmente bastante boas:
Cada um dos três pares de perguntas e respostas representa um conjunto distinto de possíveis perguntas, portanto, há uma quantidade suficiente de maneiras de configurar a conta.
Outro aspecto a considerar em relação à resposta à pergunta secreta é o armazenamento. Armazenar em texto simples no banco de dados representa quase as mesmas ameaças que no caso da senha, ou seja, a divulgação do banco de dados revela instantaneamente o valor e expõe não apenas o aplicativo, mas potencialmente outros aplicativos que usam as mesmas perguntas secretas (este é novamente ). Uma das opções é a hashing seguro (algoritmo robusto e sal criptograficamente aleatório), no entanto, ao contrário da maioria dos casos de armazenamento de senhas, pode haver uma razão válida para que a resposta seja visível como texto simples. Um cenário típico é a verificação de identidade por um operador ao telefone. É claro que, nesse caso, a hashing também se aplica (o operador pode simplesmente inserir a resposta fornecida pelo cliente), mas no pior cenário, a resposta secreta deve estar em algum nível de armazenamento criptográfico, mesmo que seja apenas uma criptografia simétrica. Em resumo: tratem segredos como segredos!
E o último aspecto das perguntas e respostas secretas — elas são mais vulneráveis ao engenharia social. Tentar diretamente extrair a senha de outra conta é uma coisa, mas fazer uma conversa sobre sua educação (uma pergunta secreta popular) é completamente diferente. Na verdade, você pode facilmente se comunicar com alguém sobre muitos aspectos de sua vida que podem representar uma pergunta secreta, e não levantar suspeitas. É claro que a essência da pergunta secreta é que está relacionada à experiência de vida de alguém, então é memorável, e é exatamente aí que está o problema — as pessoas adoram contar sobre suas experiências de vida! Pouco se pode fazer a respeito, exceto escolher opções de perguntas secretas que possam ser extraídas com menor probabilidade através de engenharia social.
[Continua...]
Em nome da publicidade
VDSina oferece servidores confiáveis , cada servidor está conectado a um canal de internet de 500 Megabits e protegido gratuitamente contra DDoS!
Fonte: habr.com
