O guia definitivo para autenticação de site baseada em formulário

votos
4k

autenticação baseada em formulários para sites

Acreditamos que estouro de pilha não deve ser apenas um recurso para questões técnicas muito específicas, mas também para orientações gerais sobre como resolver variações sobre problemas comuns. Autenticação de formulário com base em sites deve ser um tema muito bem para esse tipo de experimento.

Ela deve incluir tópicos como:

  • Como iniciar a sessão
  • Como terminar a sessão
  • Como permanecer conectado
  • Gerenciando cookies (incluindo configurações recomendadas)
  • SSL / criptografia HTTPS
  • Como armazenar senhas
  • Usando perguntas secretas
  • nome de usuário esquecido funcionalidade / password
  • Uso de nonces para prevenir cross-site request falsificações (CSRF)
  • OpenID
  • caixa de seleção Lembrar-me
  • autocompletar navegador de nomes de usuários e senhas
  • URLs secretos (público URL protegido por digest)
  • Verificando a força da senha
  • validação de E-mail
  • e muito mais sobre a autenticação baseada em formulário ...

Não deve incluir coisas como:

  • Papéis e autorização
  • autenticação básica HTTP

Por favor, ajude-nos por:

  1. sugerindo subtópicos
  2. Submeter bons artigos sobre este assunto
  3. Editando a resposta oficial
Publicado 02/08/2008 em 20:51
fonte usuário
Em outras línguas...                            


12 respostas

votos
3k

PARTE I: como fazer o login

Vamos supor que você já sabe como criar um formulário HTML de login + senha, que lança os valores para um script no lado do servidor para autenticação. As seções a seguir irão lidar com padrões de som auth prático, e como evitar as armadilhas de segurança mais comuns.

Para HTTPS ou não HTTPS?

A menos que a conexão já está seguro (isto é, encapsulado através de HTTPS usando SSL / TLS), os valores do formulário de login serão enviadas em texto puro, que permite que qualquer pessoa escutando na linha entre o navegador eo servidor web será capaz de ler logins como eles passam através. Este tipo de escutas telefônicas é feito rotineiramente pelos governos, mas em geral não abordará outros fios 'propriedade' do que dizer isto: Se você está protegendo alguma coisa importante, use HTTPS.

Em essência, a única prática maneira de proteger contra escutas telefónicas / packet sniffing durante o login é usando HTTPS ou outro esquema de criptografia baseada em certificado (por exemplo, TLS ) ou um esquema de desafio-resposta comprovada e testada (por exemplo, o Diffie-Hellman SRP com base). Qualquer outro método pode ser facilmente contornada por um atacante escutas.

Claro, se você estiver disposto a ficar um pouco impraticável, você poderia também empregam algum tipo de esquema de autenticação de dois fatores (por exemplo, o aplicativo Google Authenticator, um 'estilo Guerra Fria' livro de códigos físico, ou um dongle gerador de chaves RSA). Se aplicado corretamente, isso poderia funcionar mesmo com uma conexão não segura, mas é difícil imaginar que um dev estaria disposto a implementar de dois fatores de autenticação, mas não SSL.

(Não) Roll-seu-próprio criptografia JavaScript / hashing

Dado o custo diferente de zero e percebido dificuldade técnica de criação de um certificado SSL em seu site, alguns desenvolvedores são tentados a rolar seus próprios esquemas de hashing no navegador ou de criptografia, a fim de evitar passar logins texto puro através de um fio não segura.

Embora este seja um pensamento nobre, ele é essencialmente inútil (e pode ser uma falha de segurança ), a menos que é combinada com um dos acima - que é, quer garantir a conformidade com criptografia forte ou usando um desafio-resposta tentou-e testadas mecanismo (se você não sabe o que é, só sei que é um dos mais difíceis de provar, mais difícil de conceber, e mais difícil de implementar conceitos em segurança digital).

Embora seja verdade que hash da senha pode ser eficaz contra a divulgação de senha , é vulnerável a ataques replay, Man-In-the-middle / seqüestros (se um atacante pode injetar alguns bytes em sua página HTML não segura antes que ele atinja o seu navegador, eles podem simplesmente comentar o hashing no JavaScript), ou ataques de força bruta (desde que você está entregando o atacante tanto usuário, sal e hash de senha).

CAPTCHAS contra a humanidade

Captchas são destinadas a impedir uma determinada categoria de ataque: automatizado dicionário / força bruta de tentativa-e-erro com nenhum operador humano. Não há dúvida de que esta é uma ameaça real, no entanto, existem maneiras de lidar com ele sem problemas que não necessitam de um CAPTCHA, especificamente concebidos adequadamente serverside esquemas de login de estrangulamento - vamos discutir isso mais tarde.

Saiba que CAPTCHA implementações não são criados iguais; muitas vezes eles não são humanos-solucionáveis, 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 de sweatshop atual é de US $ 12 por 500 testes), e algumas implementações pode ser tecnicamente ilegal em alguns países (ver Folha OWASP Authentication fraude ). Se você deve usar um CAPTCHA, utilize do Google reCAPTCHA , uma vez que é OCR-duro por definição (uma vez que já OCR-misclassified scans do livro usa) e se esforça muito para ser user-friendly.

Pessoalmente, eu tendem a achar CAPTCHAS irritante, e usá-los apenas como um último recurso, quando um usuário não conseguiu iniciar sessão várias vezes e atrasos de estrangulamento são maxxed fora. Isso acontecerá raramente suficiente para ser aceitável, e fortalece o sistema como um todo.

Armazenar senhas / logins Verificando

Isto pode, finalmente, ser do conhecimento comum depois de todos os hacks altamente divulgada e vazamentos de dados do usuário que vimos nos últimos anos, mas tem que ser dito: Não armazenar senhas em texto puro no seu banco de dados. bancos de dados usuário são rotineiramente cortado, vazou ou adquirida através de injeção SQL, e se você estiver armazenando, senhas em texto puro matérias, que é um jogo instantâneo sobre para sua segurança login.

Então, se você não pode armazenar a senha, como você verificar que a combinação de login + senha Enviado a partir do formulário de login é o correto? A resposta é hash usando uma função de derivação de chaves . Sempre que um novo usuário é criado ou uma senha é alterada, você pega a senha e executá-lo através de um KDF, como Argon2, bcrypt, Scrypt ou PBKDF2, transformando a senhas em texto puro ( "correcthorsebatterystaple") em uma longa seqüência, aleatório-olhando , que é muito mais seguro para armazenar em seu banco de dados. Para verificar um login, você executar a mesma função hash na senha digitada, desta vez passando o sal e comparar a seqüência de hash resultante para o valor armazenado no seu banco de dados. Argon2, bcrypt e armazenar Scrypt o sal com já o hash. Confira este artigo sobre sec.stackexchange para informações mais detalhadas.

A razão de um sal é usado é porque hash em si não é suficiente - você vai querer adicionar um assim chamado 'sal' para proteger o hash contra tabelas do arco-íris . Um sal previne eficazmente duas senhas que correspondem exatamente de ser armazenado como o mesmo valor hash, impedindo todo o banco de dados que está sendo digitalizado em uma corrida se um atacante está executando uma adivinhação de senha ataque.

Um hash criptográfico não deve ser utilizado para o armazenamento de senha porque as senhas de utilizador seleccionada não são suficientemente forte (ou seja, não contêm geralmente suficiente entropia) e uma palavra-passe supondo ataque pode ser completada num tempo relativamente curto, por um intruso com acesso aos hash. É por isso que um KDF é usado - estas efetivamente "esticar a tecla" o que significa que cada senha acho que um atacante faz envolve a iteração o algoritmo de hash várias vezes, por exemplo, 10.000 vezes, fazendo com que a senha do atacante adivinhar 10.000 vezes mais lento.

Os dados da sessão - "Você está conectado como Spiderman69"

Uma vez que o servidor tenha verificado o login e senha contra seu banco de dados de usuário e encontrada uma correspondência, o sistema precisa de uma maneira de lembrar que o navegador tenha sido autenticado. Este fato só deve ser armazenado do lado do servidor nos dados da sessão.

Se você não estiver familiarizado com os dados da sessão, veja aqui como funciona: A única seqüência gerado aleatoriamente é armazenado em um cookie expirar e usado para fazer referência a uma coleção de dados - os dados da sessão - que é armazenado no servidor. Se você estiver usando um framework MVC, este é, sem dúvida, já tratadas.

Se possível, verifique se o cookie de sessão tem as seguras e HTTP Somente bandeiras definido quando enviado para o navegador. A bandeira httponly proporciona alguma proteção contra o cookie que está sendo lido por um ataque XSS. A bandeira seguro garante que o cookie é enviado apenas para trás via HTTPS, e, portanto, protege contra ataques sniffing de rede. O valor do cookie não deve ser previsível. Onde um cookie referenciando uma sessão inexistente é apresentado, o seu valor deve ser substituído imediatamente para evitar fixação de sessão .

PARTE II: Como permanecer conectado - The Infamous "Remember Me" Caixa de seleção

Cookies de login persistentes ( "lembrar-me" funcionalidade) são uma zona de perigo; por um lado, eles são completamente tão segura como logins convencionais quando os usuários a entender como lidar com eles; e, por outro lado, eles são um risco de segurança enorme nas mãos de usuários descuidados, que podem usá-las em computadores públicos e esquecer de fazer logout, e que podem não saber o que os cookies do navegador estão ou como excluí-los.

Pessoalmente, eu gosto logins persistentes para os sites que eu visito em uma base regular, mas eu sei como lidar com eles de forma segura. Se você é positivo que os usuários saibam o mesmo, você pode usar logins persistentes com uma consciência limpa. Se não - bem, então você pode se inscrever para a filosofia de que os usuários que são descuidados com suas credenciais de login trouxe sobre si mesmos se eles hackeado. Não é como nós vamos para as casas de nossos usuários e arrancar todos aqueles-facepalm induzir Post-It com senhas que eles se alinharam na borda de seus monitores, qualquer um.

Claro, alguns sistemas não pode dar ao luxo de ter quaisquer contas invadidas; para tais sistemas, não há nenhuma maneira você pode justificar ter logins persistentes.

Se você decidir implementar cookies de login persistentes, este é como fazê-lo:

  1. Em primeiro lugar, levará algum tempo para ler o artigo Paragon Iniciativa sobre o assunto. Você vai precisar de um monte de elementos certos, e o artigo faz um ótimo trabalho de explicar cada um.

  2. E só para reiterar uma das armadilhas mais comuns, NÃO armazenar o cookie LOGIN persistente (token) no banco de dados, apenas uma hash da TI! O token de login é senha Equivalente, por isso, se um atacante tem suas mãos em seu banco de dados, eles poderiam usar as fichas para efetuar login em qualquer conta, como se fossem combinações login-senhas em texto puro. Portanto, use hashing (de acordo com https://security.stackexchange.com/a/63438/5002 um hash fraco vai fazer muito bem para esta finalidade) ao armazenar os tokens de login persistentes.

PARTE III: Usando perguntas secretas

Não implementar 'perguntas secretas' . Recurso das perguntas secretas 'é um anti-padrão de segurança. Leia o papel da ligação de número 4 da lista de leitura obrigatória. Você pode pedir Sarah Palin sobre isso, depois de seu Yahoo! conta de e-mail ficou cortada durante uma campanha presidencial anterior, porque a resposta à sua pergunta de segurança foi ... "Wasilla High School"!

Mesmo com perguntas especificadas pelo usuário, é altamente provável que a maioria dos usuários vai escolher:

  • A pergunta secreta 'standard' como nome de solteira da mãe ou do animal de estimação favorito

  • Um simples pedaço de trivia que qualquer um poderia levantar de seu blog, perfil do LinkedIn, ou similar

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

Em conclusão, as questões de segurança são inerentemente inseguros em praticamente todas as suas formas e variações, e não deve ser empregado em um esquema de autenticação por qualquer motivo.

A verdadeira razão pela qual as questões de segurança ainda existe na natureza é que eles convenientemente economizar o custo de algumas chamadas de suporte de usuários que não podem acessar seus e-mails para chegar a um código de reativação. Isso em detrimento da segurança e reputação de Sarah Palin. Vale a pena? Provavelmente não.

PARTE IV: Forgotten funcionalidade de senha

Eu já mencionei porque você deve nunca use perguntas de segurança para lidar com esquecidos / senhas de usuário perdidas; também é preciso dizer que você nunca deve enviar um e-mail aos usuários suas senhas reais. Há pelo menos mais duas armadilhas por demais comuns a evitar nesse campo:

  1. Não redefinir uma senha esquecida para uma senha forte gerada automaticamente - tais senhas são notoriamente difíceis de lembrar, o que significa que o usuário deve ou alterá-lo ou escrevê-lo - diz, em um amarelo brilhante Post-It na borda de seu monitor. Em vez de definir uma nova senha, basta permitir que os usuários escolher um novo uma certa distância - que é o que eles querem fazer de qualquer maneira.

  2. Sempre criptografar a senha / código de token perdido no banco de dados. NOVAMENTE , este código é outro exemplo de um Equivalente senha, por isso deve ser hash no caso de um atacante tem suas mãos em seu banco de dados. Quando um código de senha perdida é solicitado, enviar o código de texto simples para o endereço de e-mail do usuário, em seguida, hash-lo, salvar o hash em seu banco de dados - e jogar fora o original . Assim como uma senha ou um token de login persistente.

Uma nota final: certifique-se sempre a sua interface para entrar no 'código de senha perdida' é pelo menos tão seguro quanto o seu formulário de login em si, ou um atacante simplesmente usar isso para obter acesso em seu lugar. Certificar-se de que você gera muito tempo 'perdido códigos de palavras-chave' (por exemplo, 16 caso caracteres alfanuméricos sensíveis) é 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: Verificando Força da senha

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

Ok, talvez a lista não é a canônica lista da maioria das senhas comuns em qualquer sistema em qualquer lugar sempre , mas é uma boa indicação de como as pessoas mal vai escolher suas senhas quando não existe uma política imposta no lugar. Além disso, a lista parece assustadoramente perto de casa quando você compará-lo com análises publicamente disponíveis de senhas recentemente roubados.

Assim: Sem requisitos mínimos de força de senha, 2% dos usuários usam um dos 20 melhores senhas mais comuns. Significado: se um atacante recebe apenas 20 tentativas, 1 em cada 50 contas em seu site vai ser atacada.

Contrariando isso requer o cálculo da entropia de uma senha e, em seguida, aplicar um limite. O Instituto Nacional de Padrões e Tecnologia (NIST) Publicação Especial 800-63 tem um conjunto de sugestões muito boas. Que, quando combinado com uma análise de dicionário e layout de 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. Basta calcular a força da senha e mostrando um medidor de força visual a um usuário é bom, mas insuficiente. A menos que seja imposta, muitos usuários provavelmente irá ignorá-lo.

E para um refrescante assumir facilidade de uso de senhas de alta entropia, de Randall Munroe xkcd Força da senha é altamente recomendado.

Parte VI: Muito Mais - Ou: Prevenção tentativas Rapid-fogo Acesso

Em primeiro lugar, ter um olhar para os números: acelera a recuperação de senha - Quanto tempo levará sua senha de pé

Se você não tem tempo para olhar através das mesas em que apontam, aqui está a lista deles:

  1. Leva quase nenhum tempo para quebrar uma senha fraca, mesmo se você está quebrando-o com um ábaco

  2. Leva quase nenhum tempo para quebrar um alfanumérico senha de 9 caracteres, se for caso insensível

  3. Leva quase nenhum tempo para quebrar uma intrincada, símbolos-e-cartas-e-números, senha superior e-minúsculas, se for menos de 8 caracteres (um PC desktop pode pesquisar todo o keyspace até 7 caracteres em uma questão de dias ou mesmo horas)

  4. Seria, no entanto, ter uma enorme quantidade de tempo para quebrar mesmo uma senha de 6 caracteres, se você estava limitado a uma tentativa por segundo!

Então o que podemos aprender com esses números? Bem, muitos, mas podemos concentrar-se na parte mais importante: o fato de que a prevenção grande número de rápido-fogo sucessivas tentativas de login (ou seja, a. Força bruta ataque) realmente não é tão difícil. Mas impedindo- direita não é tão fácil como parece.

De um modo geral, você tem três opções que são todos eficaz contra ataques de força bruta (e ataques de dicionário, mas desde que você já está empregando uma política de senhas fortes, eles não devem ser um problema) :

  • Apresentar um CAPTCHA após N tentativas falhadas (irritantes como o inferno e muitas vezes ineficaz - mas eu estou me repetindo aqui)

  • Bloqueio de contas e exigindo a verificação de e-mail após N tentativas falhadas (este é um DoS ataque à espera de acontecer)

  • E, finalmente, o login de estrangulamento : isto é, definir um intervalo de tempo entre as tentativas após N tentativas falhadas (sim, ataques DoS ainda são possíveis, mas pelo menos eles são muito menos propensos e muito mais complicado para retirar).

Melhor prática # 1: Um atraso de tempo curto que aumenta com o número de tentativas fracassadas, como:

  • 1 tentativa fracassada = nenhum atraso
  • 2 tentativas falhadas = 2 seg atraso
  • 3 tentativas falhadas = 4 seg atraso
  • 4 tentativas falhadas = 8 seg atraso
  • 5 tentativas falhadas = 16 seg atraso
  • etc.

DoS atacar este esquema seria muito pouco prático, já que o tempo de bloqueio resultante é ligeiramente maior do que a soma dos tempos de bloqueio anteriores.

Para esclarecer: O atraso é não um atraso antes de retornar a resposta para o navegador. É mais como um período de tempo limite ou refractário, durante o qual o login tentativas para uma conta específica ou de um endereço IP específico não serão aceitos ou avaliadas em tudo. Ou seja, as credenciais corretas não retornará em um login bem-sucedido, e as credenciais incorretas não vai desencadear um aumento de atraso.

Melhor prática # 2: Um atraso de tempo de comprimento médio que entra em vigor após N tentativas falhadas, como:

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

DoS atacar este esquema seria completamente impraticável, mas certamente factível. Além disso, ele pode ser relevante notar que um longo atraso pode ser muito chato para um usuário legítimo. usuários esquecidos vai gostar de você.

Melhor prática # 3: Combinando as duas abordagens - ou um, atraso de tempo curto fixo, que entra em vigor após N tentativas falhadas, como:

  • 1-4 tentativas falhadas = nenhum atraso
  • 5+ tentativas falharam = 20 seg atraso

Ou, um atraso crescente com um máximo fixado limite, como:

  • Uma tentativa falhada atraso = 5 seg
  • 2 tentativas falhadas = 15 seg atraso
  • 3+ tentativas falharam = 45 seg atraso

Este esquema final foi tomada a partir dos OWASP melhores práticas sugestões (link 1 da lista de leitura obrigatória), e deve ser considerada a melhor prática, mesmo que seja reconhecidamente no lado restritivo.

Como uma regra de ouro no entanto, eu diria: o mais forte a sua política de senha é, menos você tem que usuários de bugs com atrasos. Se você precisar de fortes (alfanuméricos case-sensitive + números e símbolos necessários) 9 + senhas de caracteres, você pode dar aos usuários 2-4 tentativas não atrasadas senha antes de ativar o estrangulamento.

DoS atacar este esquema finais de login estrangulamento seria muito pouco prático. E como um toque final, sempre permitir (cookie) logins persistentes (e / ou um formulário de login verificou-CAPTCHA) para passar, para que os usuários legítimos não vai mesmo ser adiada enquanto o ataque está em andamento . Dessa forma, o ataque DoS muito pouco prático torna-se um extremamente ataque impraticável.

Além disso, faz sentido para fazer a otimização mais agressivo em contas de administrador, já que esses são os pontos de entrada mais atraentes

Parte VII: Distribuído ataques Brute da força

Apenas como um aparte, os atacantes mais avançados vão tentar contornar estrangulamento de login por 'espalhar suas atividades':

  • Distribuir as tentativas em um botnet para evitar sinalização endereço IP

  • Em vez de escolher um usuário e tentando os 50.000 senhas mais comuns (que não podem, devido à nossa limitação), eles vão pegar a senha mais comum e experimentá-lo contra 50.000 usuários em vez. Dessa forma, não só eles contornar medidas máximas-tentativas como CAPTCHAs e estrangulamento de login, sua chance de sucesso aumenta, bem como, uma vez que o número 1 senha mais comum é muito mais provável do que o número 49,995

  • Espaçamento entre as solicitações de login para cada conta de usuário, digamos, 30 segundos de intervalo, a esgueirar-se sob o radar

Aqui, a melhor prática seria registrar o número de logins falhos, de todo o sistema , e usando uma média de execução de frequência de má-login do seu site como base para um limite superior que você, em seguida, impor a todos os usuários.

Abstrato demais? Deixe-me reformular:

Digamos que seu site teve uma média de 120 maus logins por dia durante os últimos 3 meses. Usando essa (média de execução), seu sistema pode definir o limite global para 3 vezes que - isto é. 360 tentativas ao longo de um período de 24 horas. Então, se o número total de tentativas falhadas em todas as contas excede esse número dentro de um dia (ou melhor ainda, monitorar a taxa de aceleração e gatilho em um limite calculado), ele ativa a otimização de login de todo o sistema - ou seja, atrasos curtos para todos os usuários (ainda assim, com exceção de logins de cookie e / ou logins CAPTCHA de backup).

Eu também postou uma pergunta com mais detalhes e uma boa discussão sobre como evitar pitfals complicadas em cortar distribuídos ataques de força bruta

Parte VIII: autenticação de dois fatores de autenticação e Provedores

As credenciais podem ser comprometida, seja por exploits, senhas de ser escrito e perdido, laptops com chaves que estão sendo roubados, ou os usuários de entrar logins em sites de phishing. Logins ainda pode ser protegido com a autenticação de dois fatores, que usam fatores out-of-band, tais como códigos de uso único recebidas de uma chamada de telefone, mensagem SMS, app, ou dongle. Vários provedores oferecem serviços de autenticação de dois fatores.

A autenticação pode ser completamente delegada a um serviço single-sign-on, onde um outro provedor de alças de coleta de credenciais. Isso empurra o problema para um terceiro confiável. Google e Twitter ambos fornecem serviços SSO baseados em padrões, enquanto o Facebook fornece uma solução proprietária similar.

Leitura obrigatória links sobre Autenticação Web

  1. OWASP Guide To Autenticação / Folha OWASP Authentication fraude
  2. Prós e contras de Autenticação do cliente na Web (MIT muito legível trabalho de pesquisa)
  3. Wikipedia: HTTP do cookie
  4. questões de conhecimentos pessoais para autenticação fallback: questões de segurança na era do Facebook (trabalho de pesquisa Berkeley muito legível)
Respondeu 25/01/2009 em 12:27
fonte usuário

votos
382

Definitive artigo

O envio de credenciais

A única maneira prática para enviar credenciais de 100% segura é usando SSL . Usando JavaScript para hash a senha não é segura. Armadilhas comuns para hashing de senha no lado do cliente:

  • Se a conexão entre o cliente eo servidor é criptografado, tudo que você faz é vulnerável a ataques man-in-the-middle . Um invasor pode substituir o javascript entrada para quebrar o hash ou enviar todas as credenciais para o seu servidor, eles poderiam ouvir as respostas do cliente e representar os usuários perfeitamente, SSL, etc etc com autoridades de certificação confiáveis é projetado para impedir ataques MITM.
  • O hash de senha recebida pelo servidor é menos seguro se você não fizer o trabalho adicional, redundante no servidor.

Há um outro método seguro chamado SRP , mas é patenteado (embora seja livremente licenciado ) e há alguns bons implementações disponíveis.

armazenar senhas

Nunca armazenar senhas como texto simples no banco de dados. Nem mesmo se você não se preocupam com a segurança do seu próprio site. Suponha que alguns de seus usuários vão reutilizar a senha de sua conta bancária online. Então, armazenar o hash de senha, e jogar fora o original. E certifique-se a senha não aparecer em logs de acesso ou logs de aplicativos. OWASP recomenda o uso de Argon2 como sua primeira escolha para novas aplicações. Se este não estiver disponível, PBKDF2 ou Scrypt deve ser usado em seu lugar. E finalmente, se nenhuma das opções acima estão disponíveis, use bcrypt.

Hashes por si só também são inseguras. Por exemplo, senhas idênticas significa hashes idênticos - isso faz de hash tabelas de pesquisa uma forma eficaz de quebrar um monte de senhas ao mesmo tempo. Em vez disso, guarde o salgado hash. Um sal é uma cadeia acrescentada para a palavra-passe antes de hashing - usar um sal diferente (aleatório) por utilizador. O sal é um valor público, de modo que você pode armazená-los com o hash no banco de dados. Veja aqui para saber mais sobre isso.

Isso significa que você não pode enviar o usuário suas senhas esquecidas (porque você só tem o hash). Não redefinir a senha do usuário, a menos que você tenha autenticado o usuário (usuários devem provar que são capazes de ler e-mails enviados para o endereço de e-mail armazenado (e validadas).)

Questões de segurança

Questões de segurança são inseguros - evitar usá-los. Por quê? Qualquer coisa que uma pergunta de segurança faz, uma senha faz melhor. Leia PARTE III: Usando perguntas secretas em @Jens Roland responder aqui neste wiki.

Os cookies de sessão

Depois que o usuário faz login, o servidor envia ao usuário um cookie de sessão. O servidor pode recuperar o nome de usuário ou ID do cookie, mas ninguém mais pode gerar tal cookie (TODO explicar mecanismos).

Os cookies podem ser sequestrado : eles são apenas tão seguro quanto o resto da máquina do cliente e outras comunicações. Eles podem ser lidos a partir do disco, cheirou no tráfego de rede, levantada por um cross-site scripting ataque, phished de um DNS envenenado para que o cliente envia seus cookies para os servidores erradas. Não envie cookies persistentes. Cookies devem expirar no final da sessão de cliente (navegador fechar ou deixar o seu domínio).

Se você quiser autologin seus usuários, você pode definir um cookie persistente, mas deve ser distinto de um cookie de sessão completa. Você pode definir um sinalizador adicional que o usuário tem auto-login, e precisa de login para real para as operações sensíveis. Este é popular entre os sites de compras que querem lhe proporcionar uma experiência de compra perfeita personalizado, mas ainda proteger seus dados financeiros. Por exemplo, quando você voltar para visitar Amazon, eles mostram uma página que parece que você está logado, mas quando você vai para colocar um fim (ou alterar seu endereço de entrega, cartão de crédito etc.), eles pedem-lhe para confirmar sua senha.

sites financeiros, como bancos e cartões de crédito, por outro lado, só tem dados sensíveis e não deve permitir um modo de baixa segurança auto-login ou.

Lista de recursos externos

Respondeu 02/08/2008 em 21:40
fonte usuário

votos
146

Primeiro, uma forte advertência de que esta resposta não é o mais adequado para esta pergunta exata. Ele definitivamente não deve ser a resposta de topo!

Vou ir em frente e mencionar proposta da Mozilla BrowserID (ou talvez mais precisamente, o E-mail Protocolo verificado ) no espírito de encontrar um caminho de atualização para melhores abordagens para autenticação no futuro.

Vou resumir desta forma:

  1. Mozilla é uma organização sem fins lucrativos com valores que se alinham bem com encontrar boas soluções para este problema.
  2. A realidade hoje é que a maioria dos sites usam autenticação baseada em formulários
  3. Autenticação à base de forma tem um grande inconveniente, que é o aumento do risco de phishing . Os usuários são solicitados a digitar informações sensíveis em uma área controlada por uma entidade remota, em vez de uma área controlada pelo seu User Agent (browser).
  4. Desde navegadores são implicitamente confiável (a idéia de um agente de usuário é agir em nome do usuário), eles podem ajudar a melhorar esta situação.
  5. A principal força segurando o progresso aqui é impasse implantação . As soluções devem ser decomposto em etapas que fornecem algum benefício adicional por conta própria.
  6. O método descentralizado mais simples para expressar identidade que é construído na infra-estrutura de internet é o nome de domínio.
  7. Como um segundo nível de expressão da identidade, cada domínio gere o seu próprio conjunto de contas.
  8. O formulário de “conta @de domínio” é conciso e apoiado por uma ampla gama de protocolos e esquemas URI. Tal identificador é, naturalmente, mais universalmente reconhecido como um endereço de e-mail.
  9. provedores de e-mail já são provedores de identidade principal linha de fato. fluxos de redefinição de senha atuais geralmente deixá-lo assumir o controle de uma conta se você pode provar que você controlar endereço de e-mail associado dessa conta.
  10. O Protocolo de E-mail verificado foi proposto para fornecer um método seguro, baseado em criptografia de chave pública, para agilizar o processo de provar para o domínio B que você tem uma conta no domínio A.
  11. Para navegadores que não suportam o Protocolo Email Verificado (atualmente todos eles), Mozilla oferece um calço que implementa o protocolo no lado do cliente de código JavaScript.
  12. Para os serviços de e-mail que não suportam o protocolo e-mail verificado, o protocolo permite que terceiros para agir como um intermediário de confiança, afirmando que eles já confirmou a propriedade de um usuário de uma conta. Não é desejável ter um grande número de tais terceiros; esta capacidade se destina apenas a permitir um caminho de atualização, e é muito preferido que os serviços de e-mail fornecer esses próprios afirmações.
  13. Mozilla oferece seu próprio serviço para atuar como um terceiro, confiável. Fornecedores de Serviços (isto é, as Partes Confiantes) de aplicação do Protocolo de Email Verificado podem optar por confiar em afirmações ou não da Mozilla. serviço do Mozilla verifica titularidade da conta dos usuários usando os meios convencionais de enviar um e-mail com um link de confirmação.
  14. Fornecedores de Serviços pode, é claro, oferecer este protocolo como uma opção para além de qualquer outro método (s) de autenticação que pode querer oferecer.
  15. Um benefício grande interface de usuário que está sendo procurado aqui é o “seletor de identidade”. Quando um usuário visita um site e escolhe para autenticar, o navegador mostra-lhes uma seleção de endereços de e-mail ( “pessoal”, “trabalho”, “ativismo político”, etc.) que podem usar para identificar-se para o site.
  16. Outro grande benefício interface de usuário que está sendo procurado como parte deste esforço é ajudar o navegador saber mais sobre a sessão do usuário - que eles estão conectados, como actualmente, principalmente - por isso pode indicar que no chrome browser.
  17. Devido à natureza distribuída do sistema, evita lock-in para os principais sites como o Facebook, Twitter, Google, etc. Qualquer pessoa pode possuir seu próprio domínio e, portanto, agir como seu próprio provedor de identidade.

Isto não é estritamente “autenticação baseada em formulários para sites”. Mas é um esforço para fazer a transição da norma atual de autenticação baseada em formulário para algo mais seguro: autenticação suportado-browser.

Respondeu 08/08/2011 em 16:32
fonte usuário

votos
120

Eu apenas pensei que eu iria partilhar esta solução que eu encontrei para trabalhar bem.

Eu o chamo de campo fictício (embora eu não tenha inventado isso para não me creditar).

Em suma: você só tem que inserir isso em seu <form>e verificar para que seja vazio no momento da validação:

<input type="text" name="email" style="display:none" />

O truque é enganar um bot em pensar que tem de inserir dados em um campo obrigatório, é por isso que eu nomeei o "email" de entrada. Se você já tem um campo chamado email que você está usando você deve tentar nomear o campo algo fictício mais como "empresa", "telefone" ou "endereço de email". Basta escolher algo que você sabe que você não precisa e que soa como algo que as pessoas normalmente encontrar lógica para preencher em um formulário web. Agora esconder o inputcampo usando CSS ou JavaScript / jQuery - o que você se encaixa melhor - basta não definir a entrada typepara hiddenou então o bot não vai cair para ele.

Quando você está validando a forma (cliente ou servidor) verificar se o seu campo fictício foi preenchido para determinar se ele foi enviado por um humano ou um bot.

Exemplo:

No caso de um ser humano: O usuário não verá o campo fictício (no meu caso chamado "e-mail") e não tentará preenchê-lo. Portanto, o valor do campo fictício ainda deve estar vazio quando o formulário foi enviado.

No caso de um bot: O bot vai ver um campo cujo tipo é texte um nome email(ou seja o que for que você chamou) e logicamente tentar preenchê-lo com dados apropriados. Ele não se importa se você estilo o formulário de entrada com alguma fantasia CSS, desenvolvedores web fazê-lo o tempo todo. Seja qual for o valor no campo fictício é, nós não nos importamos desde que é maior do que 0personagens.

Eu usei esse método em um livro de visitas em combinação com CAPTCHA , e eu não vi um único post de spam desde então. Eu tinha usado uma solução apenas de CAPTCHA antes, mas, eventualmente, resultou em cerca de cinco mensagens de spam a cada hora. Adicionando o campo fictício na forma parou de (pelo menos até agora) todos os spams de aparecer.

Eu acredito que este também pode ser usado muito bem com um formulário de login / autenticação.

Atenção : É claro que este método não é 100% à prova de idiotas. Bots pode ser programado para ignorar os campos de entrada com o estilo display:noneaplicado a ele. Você também tem que pensar sobre as pessoas que usam alguma forma de auto-realização (como a maioria dos navegadores têm built-in!) Para auto-preenchimento todos os campos do formulário para eles. Eles poderia muito bem pegar um campo fictício.

Você também pode variar isso um pouco a sair do campo fictício visível, mas fora dos limites da tela, mas isso é totalmente até você.

Seja criativo!

Respondeu 22/05/2012 em 13:11
fonte usuário

votos
71

Eu não acho que a resposta acima é "errado", mas existem grandes áreas de autenticação que não são tocados (ou melhor, a ênfase é sobre "como implementar sessões de cookies", não em "o que opções estão disponíveis e quais são o comércio offs".

As minhas edições sugeridas / respostas são

  • O problema reside mais em configuração da conta do que na verificação de senha.
  • O uso de dois fatores authenitication é muito mais seguro do que os meios mais inteligentes de criptografia de senha
  • Não tente implementar seu próprio formulário de login ou o armazenamento de banco de dados de senhas, a menos que os dados armazenados não tem valor na criação da conta e auto-gerado (ou seja, web estilo 2.0, como Facebook, Flickr , etc.)

    1. Autenticação Digest é uma abordagem baseada em padrões suportados em todos os principais navegadores e servidores, que não enviará uma senha, mesmo ao longo de um canal seguro.

Isso evita qualquer necessidade de ter "sessões" ou cookies como o próprio navegador irá re-criptografar a comunicação de cada vez. É a abordagem de desenvolvimento mais "leve".

No entanto, eu não recomendo este, exceto para serviços de valor público, baixos. Este é um problema com alguns dos outros respostas acima - não tente um mecanismos authetication do lado do servidor re-implementação - este problema foi resolvido e é suportado pela maioria dos principais navegadores. Não use cookies. Não guarde nada em seu próprio banco de dados enrolado à mão. Basta perguntar, por solicitação, se o pedido for autheticated. Tudo o resto deve ser suportada pelo software confiável configuração e de terceiros.

Assim ...

Em primeiro lugar, estamos confundindo a criação inicial de uma conta (com uma senha) com a re-checking da senha posteriormente. Se eu sou Flickr e criar o site pela primeira vez, o novo usuário tem acesso a valor zero (espaço em branco da web). Eu realmente não me importo se a pessoa que cria a conta está mentindo sobre o seu nome. Se eu estou criando uma conta do hospital intranet / extranet, o valor encontra-se em todos os registros médicos, e assim eu não me importo sobre a identidade (*) do criador conta.

Esta é a parte muito, muito difícil. A única solução decente é uma teia de confiança. Por exemplo, você juntar-se ao hospital como um médico. Você cria uma página web hospedada em algum lugar com sua foto, seu número de passaporte e uma chave pública, e hash-los todos com a chave privada. Você, então, visitar o hospital e o administrador do sistema olha para o seu passaporte, vê se a foto combina com você, e, em seguida, hashes o hash página web / foto com a chave privada hospital. A partir de agora, podemos seguramente trocar chaves e tokens. Como pode alguém que confia no hospital (não é o molho secreto BTW). O administrador do sistema também pode lhe dar uma RSA dongle ou outra autenticação de dois fatores.

Mas este é um monte de problemas, e não muito web 2.0. No entanto, é a única forma segura de criar novas contas que têm acesso a informações valiosas que não é auto-criado.

  1. Kerberos e SPNEGO - single sign on mecanismos com uma terceira parte confiável - basicamente o usuário verifica contra uma terceira parte confiável. (NB isso não é de forma alguma a não ser confiável OAuth )

  2. SRP - uma espécie de autenticação de senha inteligente, sem uma terceira parte confiável. Mas aqui estamos recebendo para os reinos de "é mais seguro usar autenticação de dois fatores, mesmo que seja mais caro"

  3. SSL do lado do cliente - dar aos clientes um certificado de chave pública (apoio em todos os principais navegadores - mas levanta questões sobre a segurança máquina do cliente).

No final é uma troca - o que é o custo de uma violação de segurança contra o custo de implementação de abordagens mais seguras. Um dia, poderemos ver uma adequada PKI formas de autenticação rolou e bancos de dados amplamente aceito e assim não mais própria. Um dia...

Respondeu 08/08/2011 em 17:29
fonte usuário

votos
48

Quando hash, não use algoritmos de hash rápidos, como MD5 (existem muitas implementações de hardware). Use algo como SHA-512. Para senhas, hashes mais lentos são melhores.

Quanto mais rápido você pode criar hashes, o mais rápido qualquer verificador de força bruta pode trabalhar. hashes mais lento, portanto, abrandar força bruta. Um algoritmo de hash lento vai fazer força bruta impraticável para senhas mais longas (8 dígitos +)

Respondeu 09/08/2011 em 00:07
fonte usuário

votos
46

Um bom artigo sobre estimativa de força de senha realista é:

Dropbox Tecnologia Blog »Blog Archive» zxcvbn: password realista estimativa força

Respondeu 08/11/2012 em 12:15
fonte usuário

votos
41

Minha regra favorito no que diz respeito à autenticação sistemas: usar senhas longas, não senhas. Fácil de lembrar, duro de roer. Mais informações: Coding Horror: As senhas vs. frases secretas

Respondeu 24/11/2012 em 22:15
fonte usuário

votos
20

Eu gostaria de adicionar uma sugestão que eu usei, com base na defesa em profundidade. Você não precisa ter o mesmo sistema auth e auth para administradores como usuários regulares. Você pode ter um formulário de login separado sobre uma URL separada execução de código separado para solicitações que irá conceder privilégios elevados. Este pode fazer escolhas que seria uma dor total de usuários regulares. Um desses que eu usei é realmente embaralhar o URL de login para acesso de administrador e e-mail do administrador do novo URL. Pára qualquer ataque de força bruta imediatamente como o seu novo URL pode ser arbitrariamente difícil (string aleatória muito longo), mas único inconveniente do seu usuário admin está a seguir um link em seu e-mail. O atacante já não sabe onde até mesmo post para.

Respondeu 18/07/2015 em 01:18
fonte usuário

votos
12

I dont't sei se era melhor para responder a isso como uma resposta ou como um comentário. I optou pela primeira opção.

Em relação ao poing PARTE IV: Esqueceu sua senha? Funcionalidade na primeira resposta, gostaria de fazer um ponto sobre o calendário ataques.

Nos lembre de sua senha formas, um invasor pode potencialmente conferir a lista completa de e-mails e detectar quais são registrados no sistema (ver link abaixo).

Em relação ao Formulário de senha esquecida, gostaria de acrescentar que é uma boa idéia para igualar vezes entre consultas bem-sucedidas e unsucessful com alguma função de atraso.

https://crypto.stanford.edu/~dabo/papers/webtiming.pdf

Respondeu 16/08/2015 em 17:31
fonte usuário

votos
10

Eu gostaria de adicionar um comentário muito importante:

  • "Em uma empresa, intra- configuração net", a maioria se não tudo o que precede podem não se aplicar!

Muitas corporações implantar "uso interno" sites que estão, efetivamente, "aplicações corporativas" que acontecem ter sido implementado através de URLs. Estes URLs podem (supostamente ...) só podem ser resolvidos dentro de "rede interna da empresa." (Rede que inclui magicamente tudo VPN-conectado 'guerreiros da estrada'.)

Quando um usuário está devidamente conectado à rede referida, a sua identidade ( "autenticação") é [já ...] "conclusivamente conhecido", como é a sua permissão ( "Autorização") para fazer certas coisas ... como. .. "para aceder a este site."

Este serviço "autenticação + autorização" podem ser fornecidos por várias tecnologias diferentes, como o LDAP (Microsoft OpenDirectory) , ou Kerberos.

Do seu ponto de vista, você simplesmente sabe isto: que qualquer um que legitimamente ventos-up em seu site deve "token" ser acompanhado por [um ambiente variável magicamente contendo ...] um ( Isto é, a ausência de um sinal tal, deve ser motivos imediatos para 404 Not Found.)

Valor do token não faz sentido para você, mas, em caso de necessidade, "existem meios adequados" pelo qual o seu web-site pode "[autoridade] pedir a alguém que sabe (LDAP ... etc.)" sobre qualquer e todo ( !) pergunta que você pode ter. Em outras palavras, você não aproveitar-se de qualquer "lógica home-grown". Em vez disso, você se junto das autoridades e confiar implicitamente o seu veredicto.

Uh huh ... é bastante um mentais-chave do "Internet wild-e-lanoso."

Respondeu 29/04/2015 em 01:06
fonte usuário

votos
5

Use OpenID Ligue ou acesso gerenciado pelo usuário .

Como nada é mais eficiente do que não fazê-lo em tudo.

Respondeu 10/08/2016 em 13:27
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more