O registro de falhas nas tentativas de login expõe senhas

Comecei a registrar tentativas falhas de logon no meu site com uma mensagem como

Failed login attempt by qntmfred

Notei que alguns desses logs parecem

Failed login attempt by qntmfredmypassword

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

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

Tente 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 por IP 123.45.67.89". Isso deve resolver o problema de exibir senhas acidentalmente no log.

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

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

2. O usuário digitou sua senha no campo 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 logar por usuário não identificado?

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

Considerações:

1. Você consegue detectar quando isso ocorreu, em vez de alguém digitar incorretamente o nome de usuário? Registrar nomes de usuário com erros de digitação pode ser útil para fins de suporte, ou seja, responder à pergunta "por que não consigo fazer logon" com a resposta "Você digitou seu nome de usuário com erro de digitação, que deve ser um traço, não um ponto" ou "Você tem dois pontos principais então espaço em branco - você cortou e colou ". Se você possui um pequeno número de usuários pagantes de alto valor (ou seja, ainda não é outro site de rede social), provavelmente precisará fornecer esse tipo de suporte.

2. Qual é a ação apropriada para alguém fazer isso? Os nomes de usuários podem ser indicadores de tentativas de hackers. 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 essa é uma preocupação séria e pode detectar de quem era a senha, pode exigir que o usuário altere a senha depois que isso ocorrer.

3. O que é prática da indústria? A prática da indústria é 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 da senha como sugestão 2, se você achar que isso é inadequado.

Para garantir a segurança, o login no meu aplicativo atual não armazena parâmetros passados ​​para os métodos de login ou redefinição de senha. A chamada de log possui um parâmetro opcional que controla isso, que, quando definido como true, substitui o objeto de parâmetros armazenados por [Redacted]. Claro, perdi um pouco de dados, mas tenho os endereços IP deles e prefiro não arriscar obter algo tão sensível em texto simples.

Se você realmente deseja registrar esse tipo de coisa, sugiro que, ao registrar uma tentativa de login, verifique no banco de dados se há usuários com um nome correspondente ao que você possui no campo nome de usuário e armazene-o apenas se houver uma correspondência. Caso contrário, você apenas o armazena como "usuário desconhecido". Você pode ser chique, verificando se esse valor contém isso ou algo assim, mas sempre há o risco de obter combinações como [Usuário] [Senha] e [UserPas] [espada]; nesse caso, você pode verificar o IP e deduzir que você inadvertidamente armazenou o início da senha de alguém de forma clara. Você pode estender isso para o improvável, mas possível, [User] [Password] e [UserPassword] [??]; nesse caso, você poderá ver "login mal sucedido por UserPassword" seguido de "Login bem-sucedido por usuário" e deduzir tudoda senha do usuário. Geralmente, para estar seguro, eu diria para não registrar nomes de usuário, a menos que o login seja bem-sucedido.

Edite para adicionar:

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

Por exemplo, foi dito que quando um cliente pergunta "por que não consigo fazer logon?", Os nomes de usuário registrados permitem que você aponte erros de digitação. Isso é verdade, mas não vale a pena arriscar também a captura de senhas; Eu faria isso redirecionando o usuário de volta ao formulário de logon em caso de falha, destacando o campo de nome de usuário e preenchendo-o novamente com o que eles digitaram, para que possam ver por si mesmos.

Outro argumento foi que ele permite identificar tentativas de hackers; uma série de falhas contra um nome de usuário pode muito bem ser uma tentativa de forçar uma senha com força bruta. Eu faria isso tendo uma coluna "BadLogins" na tabela Usuários, que é incrementada toda vez que um logon falha com um nome de usuário correspondente a esse usuário e é redefinida para zero em um logon bem-sucedido, depois de informar ao usuário " x tentativas malsucedidas de login desde seu último login "e aconselhando-as sobre o que fazer se não acharem que as tentativas foram delas. Se você quiser ser realmente completo, poderá ter outra coluna que armazene o último valor da coluna BadLogins, mesmo após o login bem-sucedido, e / ou uma coluna que armazene o valor mais alto dessa coluna e / ou uma coluna que armazena o número total de logins com falha que esta conta já teve.