O log de tentativas de login com falha expõe senhas

38

Eu comecei a registrar tentativas de logins com falha em meu site com uma mensagem como

Failed login attempt by qntmfred

Eu notei que alguns desses logs parecem com

Failed login attempt by qntmfredmypassword

Suponho que algumas pessoas tiveram um login com falha porque digitaram seu nome de usuário e sua senha no campo de nome de usuário. As senhas são criptografadas no banco de dados, mas se de alguma forma o banco de dados for comprometido, essas mensagens de log podem ser uma forma de um invasor descobrir senhas para qualquer pequena porcentagem de pessoas que tenham um login com falha como esse.

Existe uma maneira melhor de lidar com isso? Eu deveria me preocupar com essa possibilidade?

    
por kenwarner 22.04.2013 / 05:49
fonte

4 respostas

65

Experimente assim:

Se o nome de usuário existir, registre "falha na tentativa de login por username ". Caso contrário, registre "falha na tentativa de login pelo IP 123.45.67.89 ". Isso deve resolver o problema de ter senhas exibidas no log acidentalmente.

    
por 22.04.2013 / 05:55
fonte
12

Por que não simplesmente verificar se esse nome de usuário existe no banco de dados? Isso vai deixar você com dois possíveis resultados.

  1. O usuário digitou um nome de usuário correto. Você pode simplesmente registrar o que você registra agora.

  2. O usuário digitou sua senha no campo de nome de usuário, portanto, o nome de usuário é inválido. Basta digitar uma entrada de log informando que houve falha na tentativa de login do usuário não identificado?

E, claro, você pode ter um campo extra para registrar ip, data e quais não?

    
por 22.04.2013 / 11:29
fonte
1

Considerações:

  1. Você pode detectar quando isso ocorreu, ao contrário de alguém digitar errado seu nome de usuário? Registrar nomes de usuário incorretamente digitados pode ser útil para fins de suporte, ou seja, responder à pergunta "por que não consigo logar? em "com a resposta" Você digitou incorretamente o seu nome de usuário, que deve ser um traço não um ponto ", ou" Você tem um dois pontos à esquerda e depois um espaço em branco - você cortou e colou ". Se você tem um pequeno número de usuários pagantes de alto valor (ou seja, não é mais um site de rede social), provavelmente será necessário fornecer esse tipo de suporte.

  2. Qual é a ação apropriada se alguém fizer isso? Nomes de usuário podem ser indicadores de tentativas de invasão. O fato de o nome de usuário não aparecer na sua lista não significa que você não precisa saber o que era. No entanto, se você acredita que isso é uma preocupação séria, e você pode detectar qual senha era, você pode exigir que o usuário altere sua senha depois que isso ocorrer.

  3. O que é prática do setor? A prática do setor é registrar o campo de nome de usuário, mas não o campo de senha. É improvável que você seja demitido por fazer isso.

A menos que você tenha considerações fora do comum, sugiro seguir a prática do setor e registrar o campo de nome de usuário, independentemente. Considere as alterações forçadas de senha como sugestão 2, se achar que isso é inadequado.

    
por 22.04.2013 / 11:51
fonte
1

Só para garantir, o registro em meu aplicativo atual não armazena os parâmetros passados para os métodos de login ou de redefinição de senha. A chamada de log tem um parâmetro opcional que controla isso, que, quando definido como true, substitui o objeto de parâmetros armazenados por [Redacted] . Claro, então eu sinto falta de um pouco de dados, mas eu tenho seus endereços IP, e prefiro não arriscar obter algo tão sensível em texto simples.

Se você realmente quiser registrar esse tipo de coisa, sugiro que, ao registrar uma tentativa de login, verifique o banco de dados para usuários com um nome que corresponda ao que você tem no campo nome de usuário e armazene-o somente se você tiver uma partida. Caso contrário, você apenas armazena como "usuário desconhecido". Você pode ficar chique, verificando se esse valor contém isso ou o que for, mas há sempre o risco de obter combinações como [Usuário] [Senha] e [UserPas] [espada], caso em que você pode verificar o IP e deduzir você memorizou inadvertidamente o início da senha de alguém. Você poderia estender isso para o improvável, mas possível [Usuário] [Senha] e [UserPassword] [??], caso em que você pode ver "login sem sucesso por UserPassword" seguido por "Login bem-sucedido pelo usuário" e deduzir all da senha do usuário. Geralmente, para ser seguro, eu diria para não registrar nomes de usuários, a menos que o login seja bem-sucedido.

Editar para adicionar:

A maioria dos argumentos que as pessoas estão postando para registrar o nome de usuário para tentativas de login com falha são, na minha opinião, melhor tratadas por outros métodos.

Por exemplo, já foi dito que quando um cliente pergunta "por que não consigo logar?", os nomes de usuário registrados permitem que você aponte erros de digitação. Isso é verdade, mas não vale a pena o risco de também capturar senhas; Eu faria isso redirecionando o usuário de volta para o formulário de login em caso de falha, destacando o campo de nome de usuário e preenchendo-o novamente com qualquer coisa que ele digitasse para que eles possam ver por si mesmos.

Outro argumento foi que ele permite identificar tentativas de hackers; uma sequência de falhas contra um nome de usuário pode ser uma tentativa de forçar uma senha. Eu faria isso com uma coluna "BadLogins" na tabela Users, que é incrementada sempre que um login falha com um nome de usuário correspondente a esse usuário e é redefinido para zero em um login bem-sucedido, após informar ao usuário "houve x tentativas de login malsucedidas desde seu último login "e avisando-as sobre o que fazer se não acharem que as tentativas foram delas. Se você quer ser realmente completo, você pode ter outra coluna que armazena o último valor da coluna BadLogins, mesmo após o login bem-sucedido, e / ou uma coluna que armazena o valor mais alto da coluna, e / ou uma coluna que armazena o número total de logins com falha que esta conta já teve.

    
por 22.04.2013 / 14:43
fonte