Veja, o mundo das senhas esquecidas é, na verdade, bastante misterioso. Existem muitos pontos de vista diferentes e perfeitamente aceitáveis e muitos outros bastante perigosos. Provavelmente, você encontrou cada um deles muitas vezes como usuário final; Portanto, tentarei usar esses exemplos para mostrar quem está fazendo as coisas certas e quem não está, e no que focar para implementar adequadamente a função em seu aplicativo.
Armazenamento de senha: hashing, criptografia e (ooh!) Texto simples
Não podemos discutir o que fazer com as senhas esquecidas antes de discutirmos como armazená-las. No banco de dados, as senhas são armazenadas em um dos três tipos principais:
- Texto simples. Existe uma coluna de senha, que é armazenada em texto simples.
- . ( ), .
- . ( , ); , , , .
Vamos lidar com a questão mais simples agora: nunca armazene senhas em texto simples! Nunca. Uma única vulnerabilidade de injeção , uma cópia de backup feita inadvertidamente ou um dos vários outros erros simples - e é isso, jogador, todas as suas senhas - isto é, desculpe, todas as senhas dos seus clientes se tornarão de domínio público. Claro, isso significa uma grande possibilidade de que todas as suas senhas de todas as suas contas em outros sistemas se tornem de domínio público . E isso será sua culpa.
A criptografia é melhor, mas tem seus pontos fracos. O problema com a criptografia é a descriptografia; você pode pegar essas cifras de aparência maluca e convertê-las de volta em texto simples e, quando isso acontecer, estaremos de volta à situação com senhas legíveis. Como isso acontece? Uma pequena falha entra no código que descriptografa a senha, tornando-a publicamente disponível - esta é uma maneira. Os hackers obtêm acesso à máquina na qual os dados criptografados estão armazenados - este é o segundo método. Outra forma, novamente, é roubar o backup do banco de dados, e alguém também obtém a chave de criptografia, que geralmente é armazenada de forma insegura.
E isso nos leva ao hashing. A ideia por trás do hashing é que isso seja feito de uma maneira; a única maneira de comparar a senha inserida pelo usuário com sua versão hash é hash a senha inserida e compará-los. Para prevenir ataques com ferramentas como rainbow tables, usamos salt para adicionar aleatoriedade ao processo (leia meu post sobre armazenamento criptográfico para uma imagem completa ). Por fim, se implementado corretamente, podemos assumir com segurança que as senhas com hash nunca mais se tornarão texto simples (falarei sobre os benefícios de vários algoritmos de hash em outra postagem).
Um argumento rápido sobre hash e criptografia: A única razão pela qual você precisará criptografar em vez de hash uma senha é quando você precisa ver a senha em texto simples, e você nunca deveria querer , pelo menos não em um padrão local na rede Internet. Se você precisar, provavelmente está fazendo algo errado!
Atenção!
Abaixo, no texto da postagem, está uma parte da imagem do site pornográfico AlotPorn. Está bem recortado e, portanto, não há nada que não possa ser visto na praia, mas se ainda puder causar alguns problemas, não role a página para baixo.
Sempre redefina sua senha, nunca a lembre
Você já foi solicitado a criar um recurso de lembrete de senha? Dê um passo para trás e pense nesta solicitação 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.
Eu entendo que a palavra "lembrete" é usada (frequentemente) coloquialmente, mas o que realmente estamos tentando fazer é ajudar com segurança o usuário a ficar 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:
- — . , HTTP ( HTTPS), , . , , , , , , , . — .
- . — ( ), .
Deixe-me ilustrar o problema com usoutdoor.com como 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 oferece o envio de 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:
Não parece muito melhor, infelizmente; e o e-mail confirma o problema:
Isso nos diz dois aspectos importantes do 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 evidência em contrário.
- O site envia uma senha de longo prazo (podemos voltar e usá-la indefinidamente) por meio de um canal não seguro.
Com isso em mente, precisamos verificar se o processo de reset está sendo executado com segurança. A primeira etapa para fazer isso é garantir que o solicitante tenha o direito de realizar uma 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.
Listagem de nomes de usuário e seu impacto no anonimato
Este problema é melhor ilustrado visualmente. Problema:
Vejo? Preste atenção à mensagem "Não há usuário cadastrado com este endereço de email" ("O usuário com este endereço de email não está cadastrado"). O problema surge obviamente se um site semelhante confirmar a existência de um usuário registrado com esse endereço de e-mail. Bingo - Você acabou de descobrir o fetiche pornográfico do seu marido / chefe / vizinho!
É claro que a pornografia é um exemplo bastante canônico da importância da privacidade, mas o perigo de associar uma pessoa a um determinado site é muito mais amplo do que a situação potencialmente embaraçosa descrita acima. Um dos perigos é a engenharia social; se o invasor puder combinar a 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 porta-voz de um site e pedir mais informações em uma tentativa de spearphishing .
Práticas como essa também levantam o perigo de “enumeração de nomes de usuário”, em que se pode verificar a existência de uma coleção inteira de nomes de usuário ou endereços de e-mail em um site com consultas de grupo simples e examinar as respostas a eles. 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ê vê qual é o problema!
Qual é a alternativa? Na verdade, é bastante simples e está bem implementado no Entropay :
Aqui a Entropay não revela nada sobre a existência de um endereço de email em seu sistema para quem não possui o endereço de email . Se você possui este endereço e ele não existe no sistema, você receberá um e-mail como este:
Claro, existem situações aceitáveis em que alguém pensa que se cadastrou no site. mas não é, ou fez isso de um endereço de correio diferente. O exemplo mostrado acima lida bem com ambas as situações. Obviamente, se o endereço for igual, você receberá um e-mail facilitando a redefinição da senha.
A sutileza da solução escolhida pela Entropay é que a verificação de identidade é feita por e - mail antes de qualquer verificação online. Alguns sites fazem uma pergunta secreta aos usuários (mais sobre isso abaixo) antescomo a reinicialização pode começar; no entanto, o problema com isso é que você precisa responder à pergunta enquanto fornece 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 de uma conta de usuário anônima.
Há uma ligeira diminuição na usabilidade com essa abordagem , porque não há feedback instantâneo no caso de uma tentativa de redefinir uma conta inexistente. Claro, esse é o objetivo de enviar um e-mail, mas do ponto de vista de um usuário final real, se ele inserir o endereço errado, na primeira vez ele saberá disso apenas quando receber a carta. Isso pode causar alguma tensão em sua parte, mas é um preço pequeno a pagar por um processo tão raro.
Outra observação lateral, um pouco fora do tópico, as funções de ajuda de login que revelam o nome de usuário ou endereço de e-mail correto têm 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 de credenciais (por exemplo, “o nome de usuário está correto, mas a senha foi inserida incorretamente”).
Enviar uma senha redefinida versus enviar um url redefinido
O próximo conceito que precisamos discutir está relacionado à maneira de redefinir uma senha. Existem duas soluções populares:
- Gerar uma nova senha no servidor e enviá-la por email
- Enviar um e-mail com um URL exclusivo para simplificar o processo de redefinição
Apesar dos muitos tutoriais , o primeiro ponto nunca deve ser usado. O problema é que isso significa que há uma senha armazenada que pode ser devolvida e reutilizada a qualquer momento; foi transmitido por um canal não seguro e permanece na sua caixa de entrada. Provavelmente, as caixas de entrada são sincronizadas com dispositivos móveis e com o cliente de e-mail, além de poderem ser armazenadas online no serviço de e-mail da web por muito tempo. A questão é que a caixa de correio não pode ser vista como um meio confiável para armazenamento de longo prazo .
Mas, além disso, o primeiro parágrafo tem outro problema sério - ele simplifica o máximo possívelbloqueio de conta com intenção maliciosa. Se eu souber o endereço de e-mail do proprietário da conta no site, posso bloqueá-lo a qualquer momento simplesmente redefinindo sua senha; este é um ataque de negação de serviço, colocado em uma bandeja de prata! É por isso que a reinicialização deve ser realizada somente após uma verificação bem-sucedida com o solicitante do direito a ela.
Quando falamos sobre um URL de redefinição, estamos nos referindo a um endereço de site exclusivo para aquela instância específica do processo de redefinição . É claro que deve ser aleatório, não deve ser fácil de adivinhar e não deve conter nenhum link de conta externa para facilitar a redefinição. Por exemplo, o URL de redefinição não deve ser apenas um caminho como "Redefinir /? Nome de usuário = JohnSmith".
Queremos criar um token exclusivo que pode ser enviado por e-mail como um URL de redefinição e, em seguida, verificado em um 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 ter o formato "3ce7854015cd38c862cb9e14a1ae552b" e é armazenado na tabela junto com o ID do usuário que está redefinindo e a hora em que o token foi gerado (mais sobre isso abaixo). Ao enviar um e-mail, ele contém um URL como "Reset /? Id = 3ce7854015cd38c862cb9e14a1ae552b", e quando o usuário o carrega, a página pede a existência do token, após o qual confirma as informações do usuário e permite a alteração da senha.
Claro, como o processo acima (espero) permite que o usuário crie uma nova senha, certifique-se de que a URL seja carregada por HTTPS. Não, não é suficiente enviá-lo com uma solicitação POST por HTTPS , este URL com o token deve usar a segurança da camada de transporte para que seja impossível realizar um ataque MITM no novo formulário de entrada de senha e a senha criada pelo usuário seja transmitida por uma conexão segura.
Além disso, para o URL de redefinição, você precisa adicionar um limite de tempo de token para que o processo de redefinição possa ser executado dentro de um determinado intervalo, por exemplo, dentro de uma hora. Isso garante que a janela de redefinição seja mínima, de modo que o destinatário da URL de redefinição só possa agir dentro dessa janela muito pequena. Obviamente, o invasor pode iniciar o processo de redefinição novamente, mas precisará obter outro URL de redefinição exclusivo.
Finalmente, precisamos fazer esse processo de uma vez. Após a conclusão do processo de redefinição, o token deve ser removido para que o URL de redefinição não funcione mais. O ponto anterior é necessário para que o invasor tenha uma janela muito pequena durante a qual ele possa manipular o URL de redefinição. Além disso, é claro, após uma reinicialização bem-sucedida, o token não é mais necessário.
Algumas dessas etapas podem parecer excessivamente redundantes, mas não interferem na usabilidade e, na verdade, aumentam a segurança, embora em situações que esperamos que sejam raras. Em 99% dos casos, o usuário reinicializará em um período muito curto e não redefinirá a senha novamente em um futuro próximo.
Papel do CAPTCHA
Oh, CAPTCHA, o remédio que todos amamos odiar! Na verdade, CAPTCHA significa não tanto proteção quanto identificação - você é um ser humano ou um robô (ou um script automatizado). Seu objetivo é evitar o envio automático de formulários, o que, é claro, pode ser usado como uma tentativa de violação de segurança. No contexto da redefinição de senhas, CAPTCHA significa que a função de redefinição não pode ser quebrada à força bruta para enviar spam ao usuário ou tentar determinar a existência de contas (o que, obviamente, não será possível se você seguir o conselho da seção sobre verificação de identidade).
Claro, o CAPTCHA em si não é ideal; há muitos precedentes para seu software "hackear" e atingir taxas de sucesso suficientes (60-70%). Além disso, há uma solução mostrada em meu post sobre hackear CAPTCHAs com pessoas automatizadas onde você pode pagar às pessoas uma fração de centavo para resolver cada CAPTCHA e obter uma taxa de sucesso de 94%. Ou seja, é vulnerável, mas (ligeiramente) levanta a barreira de entrada.
Vamos dar uma olhada em um exemplo do PayPal:
Nesse caso, o processo de reinicialização simplesmente não pode ser iniciado antes que o CAPTCHA seja resolvido, portanto, é teoricamente impossível automatizar o processo. Em teoria.
No entanto, para a maioria dos aplicativos da web, isso será um exagero e definitivamente uma diminuição na usabilidade - as pessoas simplesmente não gostam de CAPTCHAs! Além disso, um CAPTCHA é algo que pode ser facilmente revisitado quando necessário. Se o serviço começar a ser atacado (o registro é útil aqui, mas mais sobre isso depois), adicionar um CAPTCHA não será mais fácil.
Perguntas e respostas secretas
Com todos os métodos que examinamos, fomos capazes de redefinir a senha apenas tendo acesso a uma conta de e-mail. Eu digo "apenas", mas é claro, obter acesso ilegal à conta de email de outra pessoa deve ser um processo difícil. No entanto, nem sempre é esse o caso .
Na verdade, o link acima sobre como hackear o Yahoo! serve a dois propósitos; primeiro, ele ilustra como é fácil hackear (algumas) contas de e-mail e, segundo, mostra como perguntas de segurança ruins podem ser usadas de forma maliciosa. Mas voltaremos a isso mais tarde.
O problema de redefinir senhas 100% dependente do e-mail é que a integridade da conta do site que você está tentando redefinir torna-se 100% dependente da integridade da conta de e-mail. 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 para todas as portas" da sua vida online.
Uma forma de atenuar esse risco é implementar um padrão de perguntas e respostas de segurança. Sem dúvida você já os viu antes: escolha uma pergunta que só você tem que respondersaber a resposta, após o qual, quando você redefinir sua senha, você será solicitado. Isso aumenta a confiança de que a pessoa que está tentando a redefinição é realmente o proprietário da conta.
De volta a Sarah Palin, o erro foi que as respostas às suas perguntas / perguntas de segurança eram fáceis de encontrar. Em particular, quando você é uma figura pública tão significativa, as informações sobre o nome de solteira de sua mãe, sua história educacional ou onde alguém pode ter vivido no passado não são tão secretos. Na verdade, a maior parte pode ser encontrada por quase qualquer pessoa. E assim aconteceu com Sarah:
O hacker David Kernell obteve acesso à conta de Palin ao encontrar suas informações de histórico, como universidade e data de nascimento, e então usar o recurso de recuperação de senha esquecida do Yahoo !.
Esta é principalmente uma falha de design da parte do Yahoo! - Ao apontar essas questões simples, a empresa essencialmente sabotou o valor da questão secreta e, portanto, a proteção de seu sistema. Claro, redefinir as senhas de uma conta de e-mail é sempre mais complicado porque você não pode provar a propriedade enviando um e-mail para o proprietário (sem ter um segundo endereço), mas felizmente não há muitas maneiras de usar este sistema hoje.
De volta às perguntas secretas - há uma opção para dar ao usuário a capacidade de criar suas próprias perguntas. O problema é que o resultado serão perguntas terrivelmente óbvias: de
que cor é o céu?
Perguntas que colocam as pessoas em uma posição incômoda quando uma pessoa usa uma pergunta de segurança para identificar(por exemplo, call center): Com
quem eu dormi no Natal?
Ou perguntas totalmente estúpidas:
como se escreve "senha"?
Quando se trata de questões de segurança, os usuários precisam ser salvos de si mesmos! Em outras palavras, a pergunta secreta deve ser determinada pelo próprio site, ou melhor, deve fazer uma série de perguntas secretas à escolha do usuário. E não escolha apenas um ; idealmente, o usuário deve selecionar duas ou mais perguntas de segurança no momento do registroque será usado como o segundo canal de identificação. Ter várias perguntas aumenta a confiança no processo de verificação, bem como 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 deve ser uma boa pergunta de segurança? Isso é influenciado por vários fatores:
- Deve ser curto - a pergunta deve ser clara e inequívoca.
- A resposta deve ser específica - não precisamos de uma pergunta que uma pessoa possa responder de maneiras diferentes
- As respostas possíveis devem ser variadas - perguntar sobre a cor favorita de alguém fornece um subconjunto muito pequeno de respostas possíveis
- — ( , ),
- — - ,
Acontece que existe um bom site de perguntas chamado GoodSecurityQuestions.com . Algumas das questões parecem ser muito boas, outras não passam em alguns dos testes descritos acima, em particular o teste de "facilidade de pesquisa".
Deixe-me mostrar como as questões de segurança são implementadas no PayPal e, em particular, quanto esforço o site faz para se identificar. Acima vimos uma página para iniciar o processo (com um CAPTCHA), mas aqui mostramos o que acontece depois que você digita seu endereço de e-mail e resolve o CAPTCHA:
Como resultado, o usuário recebe a seguinte carta:
Até agora, isso é normal, mas aqui está o que está por trás desse URL de redefinição:
Então, questões secretas 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. Eu simplesmente não consigo alterar minha senha sem responder às duas perguntas de segurança (ou saber o número do cartão). Mesmo se alguém sequestrar meu e-mail, não será capaz de redefinir a senha da minha conta do PayPal se não souber um pouco mais de informações pessoais sobre mim. Que informação? Aqui estão as opções de perguntas de segurança oferecidas pelo PayPal:
A questão da escola e do hospital pode ser um pouco duvidosa em termos de facilidade de busca, mas o resto não é tão ruim. No entanto, para melhorar a segurança, o PayPal exige identificação adicional para alterar as respostas de segurança:
O PayPal é um exemplo bastante utópico de redefinição de senha segura: ele implementa um CAPTCHA para reduzir o risco de força bruta, requer duas perguntas secretas e, em seguida, requer outro tipo de identificação completamente diferente apenas para alterar as respostas - e isso ocorre depois que o usuário já está conectado. É claro que isso é o que esperaríamos do PayPal; é uma instituição financeira que lida com grandes somas de dinheiro. Isso não significa que toda reconfiguração de senha deve seguir essas etapas - na maioria dos casos, é um exagero - mas é um bom exemplo de quando a segurança é um negócio sério.
A conveniência do sistema de perguntas secretas é que, se você não o implementou imediatamente, ele pode ser adicionado posteriormente se o nível de proteção de recursos assim o exigir. Um bom exemplo disso é a Apple, que só recentemente implementou esse mecanismo [escrito em 2012] . Assim que comecei a atualizar o aplicativo no iPad, vi a seguinte solicitação:
Então vi uma tela onde poderia selecionar vários pares de perguntas e respostas secretas, 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 e respostas representa um conjunto separado de perguntas possíveis, portanto, há várias maneiras de configurar uma conta.
Outro aspecto a considerar em relação à resposta à pergunta de segurança é o armazenamento. Encontrar texto simples no banco de dados apresenta quase as mesmas ameaças que no caso de uma senha, a saber - revelar o banco de dados instantaneamente revela o significado e coloca em risco não apenas o aplicativo, mas também aplicativos potencialmente completamente diferentes usando as mesmas questões de segurança (esta é novamente uma questão de bagas açaí) Uma opção é o hash seguro (algoritmo forte e salt criptograficamente aleatório); no entanto, ao contrário da maioria dos casos de armazenamento de senha, pode haver um bom motivo para a resposta aparecer como texto simples. Um cenário típico é uma verificação de identidade por uma operadora ao vivo por telefone. Obviamente, neste caso, o hashing também é aplicável (o operador pode simplesmente inserir a resposta nomeada pelo cliente), mas no pior caso, a resposta secreta deve estar em algum nível do armazenamento criptográfico, mesmo que seja apenas criptografia simétrica. Para resumir: trate os segredos como segredos!
E o último aspecto das perguntas e respostas secretas - elas são mais vulneráveis à engenharia social. Tentar obter diretamente uma senha para a conta de outra pessoa é uma coisa, mas iniciar uma conversa sobre sua educação (uma pergunta secreta popular) é outra bem diferente. Na verdade, você pode se comunicar de forma bastante realista com alguém sobre muitos aspectos de sua vida que podem constituir uma questão de segurança sem levantar suspeitas. Claro, a própria essência da pergunta secreta é que ela está relacionada à experiência de vida de alguém, então ela é lembrada, e esse é exatamente o problema - as pessoas adoram falar sobre suas experiências de vida! Pouco pode ser feito a respeito, apenas escolhendo as opções de questões de segurança para que sejam menos prováveis de serem retiradas pela engenharia social.
[Continua.]
Publicidade
VDSina oferece servidores confiáveis com pagamento diário , cada servidor está conectado a um canal de Internet de 500 megabits e é protegido de ataques DDoS gratuitamente!
