Pergunta

Trabalho em um sistema de login - o ponto onde o cliente escolhe a sua senha de acesso ao site.

Além de usar RegEx para garantir que a senha é forte o suficiente, normalmente em nosso sistema todos os dados que vai acabar no banco de dados é verificado contra injeção etc e um conjunto de caracteres razoavelmente restrito é aplicada em todos os campos. Eu realmente não quero um conjunto de caracteres particularmente restritiva para a senha, como eu acho que é um pouco de um anti-padrão de segurança para controlá-lo muito.

No entanto, no caso da senha, eu vou ser hash-lo com um salgado SHA-512 para inserção de qualquer maneira o que levanta um punhado de perguntas:

  • Existe algum ponto que seja em restringir o conjunto de caracteres que o cliente pode usar a senha? - ou seja, estou exposto a vulnerabilidades fora de injecção, que eu estou supondo que seria contornado completamente pelo hash

  • Deve haver negativos para um permitem-all - I pode pensar no fato de que no futuro o que é uma combinação inocente agora poderia tornar-se uma perigosa - é que uma preocupação real, e existem outros que eu pode ter perdido?

  • Existem caracteres / strings que devem ser rejeitados - que eles iriam passar a proteção ASP.NET nativa de qualquer maneira

  • ?
  • Um pouco mais subjetiva, talvez, mas, dado que é um hash SHA-512 - não há qualquer ponto em restringir o comprimento máximo de senha que o usuário pode escolher (dentro de parâmetros razoáveis), assumindo que uma senha de significativa tamanho / complexidade poderia levantar um aviso para confirmar que eles querem defini-lo.

Obrigado por sua ajuda.

EDIT:. Esta é uma aplicação web ASP.NET acessar um MSSQL2008 banco de dados usando ADO.NET (não LINQ / EF)

Foi útil?

Solução

Há pouca razão para se preocupar com ataques de inserção SQL a menos que você está realmente inserindo a senha para o banco de dados em texto simples (Perigo, Will Robertson, Perigo!) E mesmo assim se você paramaterize a consulta não será um questão. Você deve permitir [a-zA-Z0-9] mais algum conjunto de caracteres especiais. Provavelmente o único personagem para restringir é '<', que irá acionar o aviso de validação ASP.net. Há uma série de ferramentas divertidas lá fora para fazer a verificação de senha complexidade no lado do cliente. I como esta . Ele fornece um feedback imediato ao usuário como eles estão escrevendo.

Outras dicas

A partir de uma perspectiva não-Inglês - não deve haver restrições à senha.

Por exemplo, por que restringir um alto-falante de língua japonesa a usar o conjunto de caracteres US-ASCII? E por que um orador francês não usar caracteres acentuados?

Tendo em conta que o seu hash é persistiu corretamente não há nenhuma razão técnica para restringi-lo.

Uma vez que a senha é hash, ele será armazenado no banco de dados em formato hexadecimal decimal. Portanto, não vejo nenhum ponto de restringir o tipo de caracteres permitidos. Se eu quisesse usar uma letra chinesa em minha senha, eu deveria ser capaz de fazê-lo. Se tiver instalado uma extensão para o Firefox que gera bytes aleatórios e usa aqueles para minhas senhas, eu deveria ser capaz de fazê-lo. A lição aqui é não limitar as senhas dos usuários.

Observe também que RegEx tem um suporte unicode que é capaz de detectar se o usuário tiver usado uma carta de quaisquer idiomas. Isso pode tornar-se útil quando você está validando a força da senha.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top