Parte i: como aceder a

Assumiremos que já sabe como criar um formulário HTML de login+senha que publica os valores num programa do lado do servidor para Autenticação. As secções abaixo abordarão os padrões de boas práticas auth e como evitar as armadilhas de segurança mais comuns.

Para HTTPS ou não para HTTPS?

A menos que a ligação já esteja segura (Isto é, túnel através de HTTPS usando SSL/TLS), os valores do seu formulário de autenticação serão enviados cleartext, que permite que qualquer pessoa que esteja escutando a linha entre navegador e servidor web será capaz de ler logins à medida que eles passam. Este tipo de escutas é feito rotineiramente pelos governos, mas em geral não abordaremos fios "de propriedade" a não ser dizer isto: se você está protegendo alguma coisa importante, use HTTPS.

Em essência, a única forma prática de proteger contra escutas / farejamento de pacotes durante a autenticação é usando HTTPS ou outra encriptação baseada em certificados scheme (for example, TLS) or a proved & tested challenge-response scheme (for example, the Diffie-Hellman-based SRP). qualquer outro método pode ser facilmente contornado por um invasor bisbilhoteiro.

É claro que, se estiver disposto a tornar-se um pouco impraticável, Poderá também utilizar alguma forma de esquema de autenticação de dois factores (por exemplo, o aplicativo do Google autenticador, um livro de códigos físico "estilo da guerra fria" ou um dongle gerador de chaves RSA). Se aplicado correctamente, isso pode funcionar mesmo com uma conexão sem segurança, mas é difícil imaginar que um dev estaria disposto a implementar dois fatores auth, mas não SSL.

(não) rolar a sua própria encriptação/hashing JavaScript

Dado o custo não zero e a dificuldade técnica percebida de configurar um certificado SSL no seu site, alguns programadores estão tentados a rolar os seus próprios esquemas de hashing ou encriptação no navegador, a fim de evitar passar os logins de cleartext por cima de um login não garantido fio.

, Enquanto que este é um nobre pensamento, é essencialmente inútil (e pode ser um falha de segurança) a menos que ele é combinado com um dos acima - isto é, protegendo a linha com criptografia forte ou usando um experimentado e testado o mecanismo de desafio-resposta (se você não sabe o que é, só sei que é um dos mais difíceis de provar, mais difícil de design, e o mais difícil de implementar conceitos de segurança digital).

Embora seja verdade que esmagar o palavra-passe pode ser eficaz contra palavra-passe de divulgação, ele é vulnerável a ataques de repetição, Man-In-The-Middle ataques / sequestros (se um invasor pode injetar alguns bytes em sua inseguro página HTML antes de atingir o seu browser, eles podem simplesmente comentar o hash em JavaScript), ou ataques de força bruta (desde que você está entregando o invasor tanto o nome de usuário, o sal e o hash de senha).

CAPTCHAS contra a humanidade

Os CAPTCHAs são destinado a frustrar uma categoria específica de ataque: dicionário automatizado/força de teste-e-erro de Força bruta Sem operador humano. Não há dúvida de que esta é uma ameaça real, no entanto, existem maneiras de lidar com ela perfeitamente que não exigem um CAPTCHA, especificamente projetados corretamente sistemas de estrangulamento de login serverside - discutiremos esses mais tarde.

Saiba que as implementações CAPTCHA não são criadas da mesma forma; muitas vezes não são solúveis em humanos, a maioria deles são realmente ineficazes contra bots, todos eles são ineficazes contra mão-de-obra barata do Terceiro Mundo (de acordo com OWASP, a taxa atual da fábrica é de US $12 por 500 testes), e algumas implementações podem ser tecnicamente ilegais em alguns países (Ver OWASP Authentication Cheat Sheet). Se você precisa usar um CAPTCHA, use o Google reCAPTCHA , Uma vez que é OCR-hard por definição (uma vez que ele já usa scans de livros OCR-mal classificados) e tenta muito para ser fácil de usar.

Pessoalmente, tenho tendência a encontre CAPTCHAS irritantes, e use-os apenas como um último recurso quando um usuário não logar um número de vezes e os atrasos de estrangulamento estão no máximo. Isso raramente acontecerá o suficiente para ser aceitável, e fortalece o sistema como um todo.

Guardar as senhas / verificar as autenticações

Isto pode finalmente ser do conhecimento geral, depois de todos os hacks altamente publicitados e fugas de dados do utilizador que vimos nos últimos anos, mas tem de ser dito: não guarde senhas em cleartext no seu banco. As bases de dados de usuários são hackeadas, vazadas ou obtidas através de injeção de SQL, e se você estiver armazenando senhas raw, de texto simples, isso é jogo instantâneo para sua segurança de login.

Então, se você não pode armazenar a senha, como você verifica se a combinação de login+senha postada no formulário de login está correta? A resposta é amarrar usando uma função de derivação chave . Sempre que um novo utilizador é criado ou uma senha é alterada, você pega na senha e passa-a através de um KDF, como Argon2, bcrypt, scrypt ou PBKDF2, transformando a senha de cleartext ("correcthorsebatterystaple") em uma longa cadeia de aparência aleatória, que é muito mais seguro para armazenar em sua base de dados. Para verificar um login, você executa a mesma função de hash na senha introduzida, desta vez passando no salt e comparar a cadeia de hash resultante com o valor armazenado em sua base de dados. Argon2, bcrypt e scrypt armazenar o sal com o hash já. Veja este artigo sobre o sec. stackexchange para mais informações informacao.

A razão pela qual um sal é usado é porque o hashing em si não é suficiente -- você vai querer adicionar um chamado 'sal' para proteger a hash contra mesas arco-íris. Um sal impede efetivamente que duas senhas que coincidem exatamente sejam armazenadas como o mesmo valor de hash, impedindo que todo o banco de dados seja digitalizado de uma vez se um atacante estiver executando um ataque de adivinhação de senha.

Não deve ser utilizada uma barra criptográfica para o armazenamento de senhas porque as senhas selecionadas pelo Usuário não são suficientemente fortes (ou seja, geralmente não contêm entropia suficiente) e um ataque de suposição de senha pode ser concluído em um tempo relativamente curto por um atacante com acesso às hashs. É por isso que um KDF é usado-estes efetivamente "esticar a chave" significando que cada senha que um atacante faz envolve iterar o algoritmo de hashing várias vezes, por exemplo 10,000 vezes, fazendo a senha do atacante adivinhar 10,000 vezes lentamente.

Dados da sessão - "você está logado como Spiderman69"

Uma vez que o servidor tenha verificado o login e a senha no seu banco de dados de utilizadores e tenha encontrado uma correspondência, o sistema precisa de uma forma de se lembrar que o navegador foi autenticado. Este fato só deve ser armazenado lado servidor nos dados de sessão.

Se você não está familiarizado com os dados de sessão, aqui está como ele funciona: uma única cadeia gerada aleatoriamente é armazenada em um cookie expirando e usado para referencie uma coleção de dados - os dados de sessão - que é armazenada no servidor. Se você está usando um framework MVC, isso sem dúvida já é tratado.

Se for possível, certifique-se que o cookie da sessão tem as opções seguras e apenas HTTP definidas quando for enviado para o navegador. A bandeira httponly oferece alguma proteção contra o cookie ser lido por um ataque XSS. A bandeira segura garante que o cookie só é enviado de volta através de HTTPS, e, portanto, protege contra o farejamento de rede ataque. O valor do cookie não deve ser previsível. Quando um cookie que refere uma sessão inexistente é apresentado, o seu valor deve ser imediatamente substituído para evitar a fixação de sessão .

Parte II: como permanecer registado - a infame caixa de cheques" Lembra-te de mim "

Os Cookies de Login persistentes (funcionalidade "lembre-se de mim") são uma zona de perigo; por um lado, são tão seguros como os logins convencionais quando os utilizadores entendem como lidar com eles; e, por outro lado, hand, eles são um enorme risco de segurança nas mãos de usuários descuidados, que podem usá-los em computadores públicos e esquecer de sair, e que podem não saber o que são cookies de navegador ou como eliminá-los.

Pessoalmente, gosto de login persistentes para os sites que visito regularmente, mas sei como lidar com eles com segurança. Se você é positivo que seus usuários sabem o mesmo, você pode usar logins persistentes com uma consciência limpa. Se não-bem, então você pode subscrever a filosofia os utilizadores que são descuidados com as suas credenciais de login trouxeram-no a si próprios se forem hackeados. Não é como se fôssemos a casa dos nossos utilizadores e arrancássemos todas aquelas notas Post-It induzidas pelo facepalm com senhas que eles alinharam na borda dos seus monitores. É claro que alguns sistemas não se podem dar ao luxo de ter contas hackeadas; para esses sistemas, não há maneira de justificar ter logins persistentes.

Se você decidir implementar persistente cookies de login, é assim que se faz:

1. Em primeiro lugar, dedique algum tempo a ler o artigo da iniciativa Paragon sobre o assunto. Você precisa acertar um monte de elementos, e o artigo faz um ótimo trabalho de explicar cada um.

2. E apenas para reiterar uma das armadilhas mais comuns, não guarde o COOKIE de LOGIN persistente (TOKEN) na sua base de dados, apenas um HASH dele! O token de login é equivalente a senha, por isso, se um atacante tiver o seu mãos em sua base de dados, eles poderiam usar os tokens para entrar em qualquer conta, assim como se fossem combinações de login-senha de cleartext. Por conseguinte, utilizar a amarração (de acordo com https://security.stackexchange.com/a/63438/5002 um hash fraco serve perfeitamente para este fim) ao armazenar fichas de login persistentes.

Parte III: utilização de perguntas secretas

Não implemente "perguntas secretas". O recurso "perguntas secretas" é um anti-padrão de segurança. Ler o papel do link número 4 da lista MUST-READ. Podes perguntar à Sarah Palin sobre isso, depois do seu Yahoo! a conta de E-mail foi hackeada durante uma campanha presidencial anterior porque a resposta para a sua pergunta de segurança foi... "Wasilla High School"!

Mesmo com perguntas especificadas pelo Utilizador, é altamente provável que a maioria dos utilizadores escolha:

• Uma pergunta secreta "normal", como o nome de solteira da mãe ou o animal de estimação favorito

• Um simples pedaço de trivialidades que qualquer um poderia levantar de seu blog, Perfil LinkedIn, ou semelhante

• Qualquer pergunta que seja mais fácil de responder do que adivinhar a sua senha. O que, para qualquer senha decente, é cada pergunta que você pode imaginar

Em conclusão, as questões de segurança são inerentemente inseguras em praticamente todas as suas formas e variações, e não devem ser empregadas em um esquema de autenticação por qualquer razão.

A verdadeira razão pela qual a segurança questiona existem na natureza é que eles convenientemente economizar o custo de algumas chamadas de suporte de usuários que não podem acessar seu e-mail para chegar a um código de reativação. Isto à custa da segurança e da reputação da Sarah Palin. Valeu a pena? Provavelmente não.

Parte IV: funcionalidade de senha esquecida

Já mencionei porque é que nunca deve usar as questões de segurança para lidar com senhas esquecidas/perdidas de Utilizador; também é evidente que nunca deve enviar e-mails aos utilizadores que são os seus utilizadores reais. senha. Existem pelo menos mais duas armadilhas muito comuns a evitar neste domínio:

1. Não reponha uma senha esquecida a uma senha forte autogenerada - tais senhas são notoriamente difíceis de lembrar, o que significa que o utilizador deve alterá-la ou escrevê-la-digamos, num Post-It amarelo brilhante na borda do seu monitor. Em vez de definir uma nova senha, basta deixar os usuários escolher uma nova imediatamente - que é o que eles querem fazer de qualquer maneira. (Excepcao para isso pode ser se os usuários estão universalmente usando um gerenciador de senha para armazenar/gerenciar senhas que normalmente seriam impossíveis de lembrar sem escrevê-lo).

2. Anule sempre o código/símbolo de senha perdido na base de dados. outra vez., este código é outro exemplo de uma senha equivalente, então ele deve ser hashed no caso de um atacante ter suas mãos em seu banco de dados. Quando for solicitado um código de senha perdido, envie o código de texto simples para o e-mail do utilizador endereço, depois coloque-o em hash, guarde o hash na sua base de dados -- e deite fora o original . Tal como uma senha ou um login persistente.

Uma nota final: certifique-se sempre de que a sua interface para introduzir o 'código de senha perdido' é pelo menos tão segura quanto o seu próprio formulário de login, ou um atacante irá simplesmente usar isto para obter acesso em vez disso. Assegurar-se de que gera 'códigos de senha perdidos' muito longos (por exemplo, 16 caracteres alfanuméricos sensíveis a maiúsculas) é um bom começo, mas considere adicionar o mesmo esquema de estrangulamento que você faz para o próprio formulário de login.

Parte V: verificação da resistência da senha

Primeiro, vai querer ler este pequeno artigo para uma verificação da realidade: as 500 senhas mais comuns

Ok, então talvez a lista não seja a lista canónicalista das senhas mais comuns em qualquer sistema em qualquer lugar já , mas é uma boa indicação de como as pessoas vão escolher mal as suas senhas quando não há nenhuma política aplicada em vigor. Além disso, a lista parece assustadoramente perto de casa quando a comparas com análises publicamente disponíveis de senhas roubadas recentemente.

Assim: sem requisitos mínimos de resistência à senha, 2% dos utilizadores usam uma das 20 senhas mais comuns. Significa: se um atacante recebe apenas 20 tentativas, 1 em 50 contas em seu site será rachável.

Frustrar isto requer calcular a entropia de uma senha e depois aplicar um limiar. A Nível Nacional A publicação especial 800-63 ([15]) do Instituto de normas e Tecnologia (NIST) tem um conjunto de sugestões muito boas. Que, quando combinado com um dicionário e análise do layout do teclado (por exemplo, 'qwertyuiop' é uma senha ruim), pode rejeitar 99% de todas as senhas mal selecionadas a um nível de 18 bits de entropia. Calcular a força da senha e mostrar um medidor de força visual a um utilizador é bom, mas insuficiente. A menos que seja aplicada, muitos utilizadores irão provavelmente ignorá-lo.

E para uma tomada refrescante da facilidade de utilização das senhas de alta entropia, é altamente recomendada a força de senha de Randall Munroe xkcd.

Parte VI: muito mais - ou: prevenir tentativas de arranque rápido

Primeiro, dê uma olhada nos números: velocidade de recuperação de senha - quanto tempo a sua senha vai ficar de pé

Se você não tem tempo para ver as tabelas nesse link, aqui está a lista de eles:

1. Quase não é preciso tempo para decifrar uma palavra-passe fraca, mesmo que a decifres com um ábaco.

2. É preciso virtualmente nenhum tempo para quebrar uma senha alfanumérica de 9 caracteres, se for insensível à capitalização

3. É preciso virtualmente nenhum tempo para quebrar um intrincado, símbolos-e-letras-e-números, senha de maiúsculas e minúsculas, se for menos de 8 caracteres (um PC de secretária pode procurar em todo o espaço de teclas até 7 caracteres numa questão de dias ou mesmo horas)

4. Seria, no entanto, necessário uma quantidade excessiva de tempo para quebrar até mesmo uma senha de 6 caracteres, Se você fosse limitado a uma tentativa por segundo!

Então, o que podemos aprender com estes números? Bem, muitos, mas podemos nos concentrar na parte mais importante: o fato de que prevenir um grande número de tentativas sucessivas de login de fogo rápido (ou seja. o bruto a força de ataque não é assim tão difícil. Mas impedir isso não é tão fácil como parece. De um modo geral, você tem três opções que são todas eficazes contra ataques de Força bruta ([18]} (e ataques de dicionário, mas uma vez que você já está empregando uma política forte de senhas, elas não devem ser um problema):

• Apresentar uma CAPTCHA depois de N tentativas falhadas (irritante como o inferno e muitas vezes ineficaz -- mas estou a repetir-me toma.)

• Bloquear as contas e exigir a verificação por e-mail depois de N tentativas falhadas (isto é um ataque dos à espera de acontecer)

• E, finalmente, ligar a estrangular : Isto é, definir um atraso de tempo entre as tentativas após N tentativas falhadas (sim, os ataques DoS ainda são possíveis, mas pelo menos são muito menos prováveis e muito mais complicados de arrancar).

Melhores Práticas #1: um curto atraso de tempo que aumenta com o número de tentativas falhadas, como:

• 1 tentativa falhada = sem atraso
• 2 tentativas falhadas = atraso de 2 segundos
3 tentativas falhadas = atraso de 4 segundos 4 tentativas falhadas = atraso de 8 segundos
• 5 tentativas falhadas = atraso de 16 segundos
• etc.

Os ataques a este esquema seriam muito impraticáveis, uma vez que o tempo de bloqueio resultante é ligeiramente maior do que a soma dos tempos de bloqueio anteriores.

To clarificar: o atraso é não um atraso antes de devolver a resposta ao navegador. É mais como um tempo-limite ou período refratário durante o qual o login tenta uma conta específica ou a partir de um endereço IP específico não será aceito ou avaliado de todo. Ou seja, as credenciais corretas não retornarão em um login bem sucedido, e as credenciais incorretas não desencadearão um aumento de atraso.

Melhores práticas #2: um atraso de tempo médio que entra em vigor após N tentativas falhadas, como:

• 1-4 tentativas falhadas = sem atraso
• 5 tentativas falhadas = 15-30 min de atraso

Os atacar este esquema seria muito impraticável, mas certamente exequível. Além disso, pode ser relevante notar que um atraso tão longo pode ser muito irritante para um usuário legítimo. Usuários esquecidos não gostarão de você.

Melhores Práticas # 3: combinando as duas abordagens - ou um atraso de tempo fixo e curto que entra em vigor após N falhar tentativas, como:

• 1-4 tentativas falhadas = sem atraso
• 5 + tentativas falhadas = atraso de 20 segundos

Ou, um atraso crescente com um limite superior fixo, como:

• 1 tentativa falhada = atraso de 5 segundos
2 tentativas falhadas = atraso de 15 segundos
• 3 + tentativas falhadas = atraso de 45 segundos

Este esquema final foi retirado das sugestões de melhores práticas da OWASP (link 1 da lista MUST-READ) e deve ser considerado o melhor a prática, mesmo que seja reconhecidamente restritiva.

como regra geral, no entanto, eu diria: quanto mais forte a sua política de senha é, menos você tem que bug usuários com atrasos. Se necessitar de senhas de caracteres fortes (Alfanuméricos sensíveis à capitalização + números e símbolos necessários) 9+, poderá dar aos utilizadores 2 a 4 tentativas de senha não retardadas antes de activar o estrangulamento.

Os que atacarem este esquema de estrangulamento de autenticação final seriam: muito impraticável. E como toque final, sempre permitir que os logins persistentes (cookie) (e / ou um formulário de login verificado pelo CAPTCHA) passem, de modo que os usuários legítimos não serão sequer adiados enquanto o ataque está em andamento. Assim, o ataque dos muito impraticável torna-se um ataque extremamente impraticável.

Além disso, faz sentido fazer um estrangulamento mais agressivo nas contas da administração, uma vez que estes são os pontos de entrada mais atractivos

Parte VII: ataques de Força bruta distribuídos

Assim como um aparte, os atacantes mais avançados tentarão contornar o estrangulamento do login "espalhando as suas actividades": {[[4]}

• Distribuir as tentativas de um botnet para evitar a marcação de endereços IP

• Em vez de escolher um usuário e tentar as 50.000 senhas mais comuns (que eles não podem, por causa do nosso estrangulamento), eles vão escolher a senha mais comum e tentar contra 50.000 usuários em vez disso. Por ali, não. apenas eles conseguem contornar as medidas de tentativas máximas como CAPTCHAs e o estrangulamento de login, a sua chance de sucesso também aumenta, uma vez que a senha mais comum número 1 é muito mais provável do que Número 49.995

• Espaçando os pedidos de login para cada conta de usuário, digamos, 30 segundos de intervalo, para esgueirar-se sob o radar

Aqui, a melhor prática seria registar o número de logins falhados, em todo o sistema, e usar uma média de execução do seu site Bad-login frequency as the basis for an upper limit that you then impose on all users.

Demasiado abstracto? Deixa-me reformular. Diga que o seu site teve uma média de 120 Bad logins por dia nos últimos 3 meses. Usando isso (running average), o seu sistema poderá definir o limite global para 3 vezes o -- ie. 360 tentativas falhadas ao longo de um período de 24 horas. Então, se o número total de tentativas falhadas em todas as contas exceder esse número dentro de um dia (ou ainda melhor, monitorar a taxa de aceleração e trigger em um limiar calculado), ele ativa a aceleração de login em todo o sistema - significando pequenos atrasos para todos os usuários (ainda, com exceção de logins de cookie e/ou logins de backup CAPTCHA). Também coloquei uma pergunta com mais detalhes e uma boa discussão sobre como evitar os traiçoeiros ataques de Força bruta distribuídos.

Parte VIII: fornecedores de autenticação e autenticação com dois factores

As credenciais podem ser comprometido, seja por façanhas, senhas sendo escritas e perdidas, laptops com chaves sendo roubadas, ou usuários entrando logins em sites de phishing. Logins podem ser protegidos com autenticação de dois fatores, que usam fatores fora de banda, como códigos de uso único recebidos de uma chamada de telefone, mensagem SMS, aplicativo ou dongle. Vários provedores oferecem serviços de autenticação de dois fatores.

A autenticação pode ser completamente delegada num serviço de sinal único, onde outro fornecedor lida com a recolha de credenciais. Isso empurra o problema para um terceiro confiável. O Google e o Twitter fornecem serviços SSO baseados em padrões, enquanto o Facebook fornece uma solução proprietária semelhante.

MUST-READ LINKS About Web Authentication

1. OWASP Guide To Authentication / OWASP Authentication Cheat Sheet
2. dos and Don'ts of Client Authentication on the Web (very readable MIT research papel)
3. Wikipédia: 'cookie' de HTTP
4. questões de conhecimento pessoal para autenticação de retorno: questões de segurança na Era do Facebook (muito legível Berkeley research paper)