Recentemente, tive tempo para pensar novamente sobre como um recurso seguro de redefinição de senha deveria funcionar, primeiro quando eu estava incorporando essa funcionalidade no , e então quando ele ajudou outra pessoa a fazer algo semelhante. No segundo caso, queria fornecer a ele um link para um recurso canônico com todos os detalhes de como implementar com segurança a função de redefinição. Porém, o problema é que tal recurso não existe, pelo menos não um que descreva tudo o que me parece importante. Então decidi escrever sozinho.
Veja, o mundo das senhas esquecidas é na verdade bastante misterioso. Existem muitos pontos de vista diferentes e completamente aceitáveis e muitos outros bastante perigosos. Provavelmente, você já encontrou cada um deles muitas vezes como usuário final; então tentarei usar esses exemplos para mostrar quem está fazendo certo, quem não está e no que você precisa se concentrar para obter o recurso certo em seu aplicativo.
Armazenamento de senhas: hashing, criptografia e (suspiro!) texto simples
Não podemos discutir o que fazer com senhas esquecidas antes de discutirmos como armazená-las. As senhas são armazenadas no banco de dados em um dos três tipos principais:
- Texto simples. Existe uma coluna de senha, que é armazenada em formato de texto simples.
- Criptografado. Normalmente usa criptografia simétrica (uma chave é usada para criptografia e descriptografia), e as senhas criptografadas também são armazenadas na mesma coluna.
- Hasheado. Processo unidirecional (a senha pode ser hash, mas não pode ser descodificada); senha, Eu gostaria de ter esperança, seguido de um sal, e cada um está em sua coluna.
Vamos direto à pergunta mais simples: Nunca armazene senhas em texto simples! Nunca. Uma única vulnerabilidade para , um backup descuidado ou um entre dezenas de outros erros simples - e pronto, fim do jogo, todas as suas senhas - ou seja, desculpe, senhas de todos os seus clientes se tornará domínio público. Claro, isso significaria uma enorme probabilidade de que de todas as suas contas em outros sistemas. E a culpa será sua.
A criptografia é melhor, mas tem seus pontos fracos. O problema da criptografia é a descriptografia; podemos pegar essas cifras malucas e convertê-las de volta em texto simples e, quando isso acontecer, voltaremos à situação de senha legível por humanos. Como isso acontece? Uma pequena falha entra no código que descriptografa a senha, tornando-a publicamente disponível – essa é uma maneira. Os hackers obtêm acesso à máquina na qual os dados criptografados são armazenados - este é o segundo método. Outra maneira, novamente, é roubar o backup do banco de dados e alguém também obter a chave de criptografia, que geralmente é armazenada de forma muito insegura.
E isso nos leva ao hash. A ideia por trás do hash é que ele seja unilateral; a única maneira de comparar a senha inserida pelo usuário com sua versão com hash é fazer o hash da entrada e compará-las. Para evitar ataques de ferramentas como tabelas arco-íris, salgamos o processo com aleatoriedade (leia meu sobre armazenamento criptográfico). Em última análise, se implementadas corretamente, podemos ter certeza de que as senhas com hash nunca mais se tornarão texto simples (falarei sobre os benefícios de diferentes algoritmos de hash em outro post).
Um argumento rápido sobre hash versus criptografia: o único motivo pelo qual você precisa criptografar em vez de hash uma senha é quando você precisa ver a senha em texto simples e você nunca deveria querer isso, pelo menos em uma situação padrão de site. Se você precisar disso, provavelmente está fazendo algo errado!
Atenção!
Abaixo no texto do post há parte de uma captura de tela do site pornográfico AlotPorn. Está bem aparado para que não haja nada que você não possa ver na praia, mas se ainda puder causar algum problema, não role para baixo.
Sempre redefina sua senha nunca não lembre ele
Você já foi solicitado a criar uma função lembretes senha? Dê um passo para trás e pense neste pedido ao contrário: por que esse “lembrete” é necessário? Porque o usuário esqueceu a senha. O que realmente queremos fazer? Ajude-o a fazer login novamente.
Sei que a palavra "lembrete" é usada (frequentemente) num sentido coloquial, mas o que estamos realmente tentando fazer é ajude com segurança o usuário a estar online novamente. Como precisamos de segurança, há dois motivos pelos quais um lembrete (ou seja, enviar sua senha ao usuário) não é apropriado:
- O e-mail é um canal inseguro. Assim como não enviaríamos nada confidencial por HTTP (usaríamos HTTPS), não deveríamos enviar nada confidencial por e-mail porque sua camada de transporte é insegura. Na verdade, isto é muito pior do que simplesmente enviar informações através de um protocolo de transporte inseguro, porque o correio é frequentemente armazenado num dispositivo de armazenamento, acessível aos administradores do sistema, encaminhado e distribuído, acessível a malware, e assim por diante. E-mail não criptografado é um canal extremamente inseguro.
- Você não deveria ter acesso à senha de qualquer maneira. Releia a seção anterior sobre armazenamento - você deve ter um hash da senha (com um sal forte e bom), o que significa que você não deve conseguir de forma alguma extrair a senha e enviá-la por correio.
Deixe-me demonstrar o problema com um exemplo : Aqui está uma página de login típica:
Obviamente, o primeiro problema é que a página de login não carrega via HTTPS, mas o site também solicita o envio de uma senha (“Enviar Senha”). Este pode ser um exemplo do uso coloquial do termo mencionado acima, então vamos dar um passo adiante e ver o que acontece:
Infelizmente, não parece muito melhor; e um e-mail confirma que há um problema:
Isso nos diz dois aspectos importantes de usoutdoor.com:
- O site não faz hash de senhas. Na melhor das hipóteses, eles são criptografados, mas é provável que sejam armazenados em texto simples; Não vemos nenhuma evidência em contrário.
- O site envia uma senha de longo prazo (podemos voltar e usá-la repetidas vezes) por meio de um canal não seguro.
Com isso resolvido, precisamos verificar se o processo de redefinição é feito de forma segura. O primeiro passo para fazer isso é certificar-se de que o solicitante tem o direito de realizar a redefinição. Em outras palavras, antes disso precisamos de uma verificação de identidade; vamos dar uma olhada no que acontece quando uma identidade é verificada sem primeiro verificar se o solicitante é realmente o proprietário da conta.
Listando nomes de usuário e seu impacto no anonimato
Este problema é melhor ilustrado visualmente. Problema:
Você vê? Preste atenção na mensagem “Não há usuário cadastrado com este endereço de e-mail”. O problema surge obviamente se tal site confirmar disponibilidade 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 a pornografia é um exemplo bastante icónico da importância da privacidade, mas os perigos de associar uma identidade a um website específico são muito mais amplos do que a situação potencialmente embaraçosa descrita acima. Um perigo é a engenharia social; Se o invasor conseguir combinar uma pessoa com o serviço, ele terá informações que poderá começar a usar. Por exemplo, ele pode entrar em contato com uma pessoa que se faz passar por representante de um site e solicitar informações adicionais na tentativa de cometer .
Tais práticas também aumentam o perigo da “enumeração de nomes de utilizadores”, através da qual se pode verificar a existência de uma coleção inteira de nomes de utilizadores ou endereços de e-mail num website, simplesmente realizando consultas em grupo e examinando as respostas a elas. Você tem uma lista de endereços de e-mail de todos os funcionários e alguns minutos para escrever um roteiro? Então você vê qual é o problema!
Qual é a alternativa? Na verdade, é bastante simples e é maravilhosamente implementado em :
Aqui a Entropay não divulga absolutamente nada sobre a existência de um endereço de e-mail em seu sistema para alguém que não possui este endereço... Se você ter este endereço e ele não existe no sistema, você receberá um e-mail como este:
Claro, pode haver situações aceitáveis em que alguém pensaque você se registrou no site. mas não é o caso, ou fiz isso de um endereço de e-mail diferente. O exemplo mostrado acima lida bem com ambas as situações. Obviamente, se o endereço corresponder, você receberá um e-mail facilitando a redefinição de sua senha.
A sutileza da solução escolhida pela Entropay é que a verificação da identificação é realizada de acordo com e-mail antes de qualquer verificação online. Alguns sites pedem aos usuários a resposta a uma pergunta de segurança (mais sobre isso abaixo) para como a reinicialização pode começar; entretanto, o problema com isso é que você deve responder à pergunta fornecendo alguma forma de identificação (e-mail ou nome de usuário), o que torna quase impossível responder intuitivamente sem revelar a existência da conta do usuário anônimo.
Com esta abordagem há um pequeno diminuição da usabilidade porque se você tentar redefinir uma conta inexistente, não haverá feedback imediato. Claro, esse é o objetivo do envio de um e-mail, mas do ponto de vista do usuário final real, se ele inserir o endereço errado, ele só saberá pela primeira vez quando receber o e-mail. Isso pode causar alguma tensão da parte dele, mas é um preço pequeno a pagar por um processo tão raro.
Outra observação, um pouco fora do assunto: as funções de assistência de login que revelam se um nome de usuário ou endereço de e-mail estão corretos apresentam o mesmo problema. Sempre responda ao usuário com uma mensagem “Sua combinação de nome de usuário e senha é inválida” em vez de confirmar explicitamente a existência das credenciais (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 é como redefinir sua senha. Existem duas soluções populares:
- Gerando uma nova senha no servidor e enviando por email
- Envie um e-mail com um URL exclusivo para facilitar o processo de redefinição
Apesar de , o primeiro ponto nunca deve ser usado. O problema com isso é que significa que há senha armazenada, ao qual você pode retornar e usar novamente a qualquer momento; ele foi enviado por um canal inseguro e permanece na sua caixa de entrada. É provável que as caixas de entrada sejam sincronizadas entre dispositivos móveis e o cliente de e-mail, além de poderem ser armazenadas online no serviço de e-mail da web por muito tempo. O ponto é que uma caixa de correio não pode ser considerada um meio confiável de armazenamento a longo prazo.
Mas, além disso, o primeiro ponto tem outro problema sério - é simplifica ao máximo bloquear uma conta com intenção maliciosa. Se eu souber o endereço de e-mail de alguém que possui uma conta em um site, posso bloqueá-lo a qualquer momento, simplesmente redefinindo sua senha; Este é um ataque de negação de serviço servido em uma bandeja de prata! É por isso que a redefinição só deve ser realizada após a verificação bem-sucedida dos direitos do solicitante sobre ela.
Quando falamos sobre um URL de redefinição, queremos dizer o endereço de um site que é exclusivo para este caso específico do processo de reinicialização. Claro, deve ser aleatório, não deve ser fácil de adivinhar e não deve conter nenhum link externo para a conta que facilite a redefinição. Por exemplo, o URL de redefinição não deve ser simplesmente um caminho como "Reset/?username=JohnSmith".
Queremos criar um token exclusivo que possa ser enviado como uma URL de redefinição e, em seguida, comparado ao registro do servidor da conta do usuário, confirmando assim que o proprietário da conta é, de fato, a mesma pessoa que está tentando redefinir a senha. Por exemplo, um token pode ser "3ce7854015cd38c862cb9e14a1ae552b" e armazenado em uma tabela junto com o ID do usuário que está realizando a redefinição e a hora em que o token foi gerado (mais sobre isso abaixo). Quando o e-mail é enviado, ele contém uma URL como “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b”, e quando o usuário faz o download, a página solicita a existência do token, após o que confirma as informações do usuário e permite alterar o senha.
Claro, como o processo acima (espero) permite que o usuário crie uma nova senha, precisamos garantir que a URL seja carregada por HTTPS. Não, , esse URL de token deve usar a segurança da camada de transporte para que o novo formato de senha não possa ser atacado e a senha criada pelo usuário foi transmitida por uma conexão segura.
Também para o URL de redefinição, você precisa adicionar um limite de tempo de token para que o processo de redefinição possa ser concluído dentro de um determinado intervalo, digamos, dentro de uma hora. Isso garante que a janela de tempo de redefinição seja mantida no mínimo, para que o destinatário da URL de redefinição possa agir somente dentro dessa janela muito pequena. É claro que o invasor pode iniciar o processo de redefinição novamente, mas precisará obter outro URL de redefinição exclusivo.
Finalmente, precisamos garantir que este processo seja descartável. Assim que o processo de redefinição for concluído, o token deverá ser removido para que o URL de redefinição não funcione mais. O ponto anterior é necessário para garantir que o invasor tenha uma janela muito pequena durante a qual possa manipular a URL de redefinição. Além disso, é claro, quando a redefinição for bem-sucedida, o token não será mais necessário.
Algumas dessas etapas podem parecer excessivamente redundantes, mas não interferem na usabilidade e de fato melhorar a segurança, embora em situações que esperamos que sejam raras. Em 99% dos casos, o usuário ativará a redefinição em um período muito curto de tempo e não redefinirá a senha novamente em um futuro próximo.
Papel do CAPTCHA
Ah, CAPTCHA, o recurso de segurança que todos amamos odiar! Na verdade, o CAPTCHA não é tanto uma ferramenta de proteção, mas sim uma ferramenta de identificação – seja você uma pessoa ou um robô (ou um script automatizado). Seu objetivo é evitar o envio automático de formulários, o que, obviamente, lata ser usado como uma tentativa de quebrar a segurança. No contexto de redefinições de senha, CAPTCHA significa que a função de redefinição não pode ser submetida à força bruta para enviar spam ao usuário ou tentar determinar a existência de contas (o que, é claro, não será possível se você seguir os conselhos da seção sobre verificação de identidades).
É claro que o CAPTCHA em si não é perfeito; Existem muitos precedentes para o seu software “hackear” e alcançar taxas de sucesso suficientes (60-70%). Além disso, há uma solução mostrada em minha postagem sobre , onde você pode pagar às pessoas frações de centavo para resolver cada CAPTCHA e alcançar uma taxa de sucesso de 94%. Ou seja, é vulnerável, mas aumenta (ligeiramente) a barreira de entrada.
Vamos dar uma olhada no exemplo do PayPal:
Neste caso, o processo de redefinição simplesmente não pode começar até que o CAPTCHA seja resolvido, então teoricamente é impossível automatizar o processo. Em teoria.
No entanto, para a maioria das aplicações web isso será um exagero e absolutamente certo representa uma diminuição na usabilidade – as pessoas simplesmente não gostam de CAPTCHA! Além disso, CAPTCHA é algo ao qual você pode retornar facilmente, se necessário. Se o serviço começar a ser atacado (é aqui que o registro é útil, mas falaremos mais sobre isso depois), adicionar um CAPTCHA não poderia ser mais fácil.
Perguntas e respostas secretas
Com todos os métodos que consideramos, conseguimos redefinir a senha apenas tendo acesso à conta de e-mail. Digo “apenas”, mas, claro, é ilegal obter acesso à conta de email de outra pessoa. deveria ser um processo complexo. No entanto .
Na verdade, o link acima sobre a invasão do Yahoo! de Sarah Palin! serve a dois propósitos; em primeiro lugar, ilustra como é fácil hackear (algumas) contas de e-mail e, em segundo lugar, mostra como perguntas de segurança ruins podem ser usadas com intenções maliciosas. Mas voltaremos a isso mais tarde.
O problema com redefinições de senha XNUMX% baseadas em email é que a integridade da conta do site que você está tentando redefinir torna-se XNUMX% dependente da integridade da conta de email. Qualquer pessoa que tenha acesso ao seu e-mail tem acesso a qualquer conta que pode ser redefinida simplesmente recebendo um e-mail. Para essas contas, o e-mail é a “chave de todas as portas” da sua vida online.
Uma maneira de reduzir esse risco é implementar um padrão de perguntas e respostas de segurança. Sem dúvida você já as viu: escolha uma pergunta que só você possa responder ter saiba a resposta e, quando você redefinir sua senha, ela será solicitada. Isso aumenta a confiança de que a pessoa que está tentando redefinir é de fato o proprietário da conta.
De volta a Sarah Palin: o erro foi que as respostas às suas perguntas/perguntas de segurança puderam ser facilmente encontradas. Especialmente quando você é uma figura pública tão importante, informações sobre o nome de solteira de sua mãe, histórico educacional ou onde alguém pode ter vivido no passado não são tão secretas. Na verdade, a maior parte pode ser encontrada por quase qualquer pessoa. Isto é o que aconteceu com Sara:
O hacker David Kernell obteve acesso à conta de Palin encontrando detalhes sobre seu histórico, como universidade e data de nascimento, e depois usando o recurso de recuperação de senha esquecida do Yahoo!.
Em primeiro lugar, este é um erro de design por parte do Yahoo! — ao especificar questões tão simples, a empresa sabotou essencialmente o valor da questão de segurança e, portanto, a proteção do seu sistema. É claro que redefinir senhas de uma conta de e-mail é sempre mais difícil, pois você não pode provar a propriedade enviando um e-mail ao proprietário (sem ter um segundo endereço), mas felizmente não há muitos usos para criar tal sistema hoje.
Voltemos às questões de segurança – existe uma opção que permite ao usuário criar suas próprias perguntas. O problema é que isso resultará em questões terrivelmente óbvias:
Qual é a cor do céu?
Perguntas que deixam as pessoas desconfortáveis quando uma pergunta de segurança é usada para identificar pessoas (por exemplo, em um call center):
Com quem eu dormi no Natal?
Ou perguntas francamente estúpidas:
Como você soletra "senha"?
Quando se trata de questões de segurança, os usuários precisam ser salvos de si mesmos! Em outras palavras, a questão de segurança deve ser determinada pelo próprio site, ou melhor ainda, feita séries questões de segurança que o usuário pode escolher. E não é fácil escolher um; idealmente, o usuário deve selecionar duas ou mais perguntas de segurança no momento do registro da conta, que será então utilizado como segundo canal de identificação. Ter múltiplas perguntas aumenta a confiança no processo de verificação e também fornece a capacidade de adicionar aleatoriedade (nem sempre mostrando a mesma pergunta), além de fornecer um pouco de redundância caso o usuário real tenha esquecido a senha.
Qual é uma boa pergunta de segurança? Isso é influenciado por vários fatores:
- Ele deve ser apresentação — a pergunta deve ser clara e inequívoca.
- A resposta deve ser específico - não precisamos de uma pergunta que uma pessoa possa responder de maneira diferente
- As possíveis respostas devem ser diverso - perguntar a cor favorita de alguém produz um subconjunto muito pequeno de respostas possíveis
- Pesquisa a resposta deve ser complexa - se a resposta puder ser facilmente encontrada qualquer (lembre-se de pessoas em altos cargos), então ele é mau
- A resposta deve ser permanente com o tempo - se você perguntar qual é o filme favorito de alguém, um ano depois a resposta pode ser diferente
Na verdade, existe um site dedicado a fazer boas perguntas chamado . Algumas questões parecem bastante boas, outras não passam em alguns dos testes descritos acima, especialmente no teste de “facilidade de pesquisa”.
Deixe-me demonstrar como o PayPal implementa questões de segurança e, em particular, o esforço que o site coloca na autenticação. Acima vimos a página para iniciar o processo (com um CAPTCHA), e aqui mostraremos o que acontece após você inserir seu endereço de e-mail e resolver o CAPTCHA:
Como resultado, o usuário recebe a seguinte carta:
Até agora tudo está normal, mas aqui está o que está escondido por trás deste URL de redefinição:
Portanto, questões de segurança entram em jogo. Na verdade, o PayPal também permite que você redefina sua senha verificando o número do seu cartão de crédito, portanto, há um canal adicional ao qual muitos sites não têm acesso. Simplesmente não consigo alterar minha senha sem responder ambos pergunta de segurança (ou não saber o número do cartão). Mesmo que alguém sequestrasse meu e-mail, não seria capaz de redefinir a senha da minha conta do PayPal, a menos que soubesse mais algumas informações pessoais sobre mim. Que informação? Aqui estão as opções de perguntas de segurança que o PayPal oferece:
A questão da escola e do hospital pode ser um pouco duvidosa em termos de facilidade de pesquisa, mas as outras não são tão ruins. No entanto, para aumentar a segurança, o PayPal exige identificação adicional para mudanças respostas a perguntas de segurança:
O PayPal é um exemplo bastante utópico de redefinições de senha seguras: ele implementa um CAPTCHA para reduzir o perigo de ataques de força bruta, exige duas perguntas de segurança e, em seguida, exige outro tipo de identificação completamente diferente apenas para alterar as respostas – e isso depois que o usuário já fez login. Claro, isso é exatamente o que nós esperado do PayPal; é uma instituição financeira que lida com grandes somas de dinheiro. Isso não significa que toda redefinição de senha precise seguir essas etapas – na maioria das vezes é um exagero – mas é um bom exemplo para casos em que a segurança é um assunto sério.
A conveniência do sistema de perguntas de segurança é que, se você não o implementou imediatamente, poderá adicioná-lo mais tarde, se o nível de proteção de recursos exigir. Um bom exemplo disso é a Apple, que só recentemente implementou este mecanismo [artigo escrito em 2012]. Assim que comecei a atualizar o aplicativo no meu iPad, vi a seguinte solicitação:
Então vi uma tela onde poderia selecionar vários pares de perguntas e respostas de segurança, bem como um endereço de e-mail de resgate:
Quanto ao PayPal, as perguntas são pré-selecionadas e algumas delas são realmente muito boas:
Cada um dos três pares de perguntas/respostas representa um conjunto diferente de perguntas possíveis, portanto, há muitas maneiras de configurar uma conta.
Outro aspecto a considerar ao responder à sua pergunta de segurança é o armazenamento. Ter um banco de dados de texto simples no banco de dados representa quase as mesmas ameaças que uma senha, ou seja, a exposição do banco de dados revela instantaneamente o valor e coloca não apenas o aplicativo em risco, mas potencialmente aplicativos completamente diferentes usando as mesmas questões de segurança (lá novamente ). Uma opção é o hashing seguro (um algoritmo forte e um sal criptograficamente aleatório), mas, diferentemente da maioria dos casos de armazenamento de senhas, pode haver um bom motivo para a resposta ser visível como texto simples. Um cenário típico é a verificação de identidade por uma operadora telefônica ao vivo. É claro que o hash também é aplicável neste caso (o operador pode simplesmente inserir a resposta nomeada pelo cliente), mas na pior das hipóteses, a resposta secreta deve estar localizada em algum nível de armazenamento criptográfico, mesmo que seja apenas criptografia simétrica. . Resumir: trate segredos como segredos!
Um aspecto final das perguntas e respostas de segurança é que elas são mais vulneráveis à engenharia social. Tentar extrair diretamente a senha da conta de outra pessoa é uma coisa, mas iniciar uma conversa sobre sua formação (uma pergunta de segurança popular) é completamente diferente. Na verdade, você pode muito bem se comunicar com alguém sobre muitos aspectos de sua vida que podem representar uma questão secreta sem levantar suspeitas. É claro que o objetivo de uma pergunta de segurança é que ela se relaciona com a experiência de vida de alguém, por isso é memorável, e é aí que reside o problema - as pessoas adoram falar sobre suas experiências de vida! Há pouco que você possa fazer sobre isso, apenas se você escolher essas opções de perguntas de segurança para que elas sejam menor provavelmente poderia ser retirado pela engenharia social.
[Continua.]Como a publicidade
VDSina oferece confiável , cada servidor está conectado a um canal de Internet de 500 Megabits e protegido contra ataques DDoS gratuitamente!
Fonte: habr.com