Quais são as melhores regras a seguir para o que caracteres para permitir a entrada de uma senha?

Question

Sem pensar em tudo que eu só quero dizer que eu deveria permitir que cada personagem. Ele fica hash em qualquer caso, e eu não quero limitar as pessoas que querem criar senhas fortes.

No entanto, pensando nisso mais, há uma abundância de personagens que eu não tenho nenhuma idéia do efeito que eles têm sobre as coisas. caracteres estrangeiros, símbolos ASCII, etc, para citar alguns.

Eu tentei Google, mas não consigo encontrar nenhum padrão definitivo para que as pessoas fazem. Mesmo a maioria das organizações profissionais não parecem saber. Parece ser uma prática comum para muitos sites para não permitir caracteres especiais por completo, o que é bobagem e não o que eu quero fazer.

De qualquer forma, existem recomendações padrão para comprimento, caracteres permitidos, e assim por diante?

Eu não tenho certeza se isso importa, mas eu vou estar usando ASP.NET w / C #

Answer 1

Qualquer, caracteres ASCII não-espaço em branco para impressão (entre 33 e 126 inclusive) são normalmente permitido em senhas. muitos profissionais de segurança (e comentadores SO) estão aconselhando o uso de um senha no lugar de uma senha , então você teria que permite espaços. O argumento é que, devido ao seu comprimento, e desde frases não estão em um dicionário, frases secretas são mais difíceis de decifrar do que senhas. (A senha também pode ser mais fácil de lembrar, assim que um usuário legítimo não tem que mantê-lo escrito em um certo pegajoso-nota em seu monitor.)

Alguns fortes geradores de senha usam um hash, então eu colocar um limite muito alto o comprimento (512 ou 1024) apenas para ser inclusivo. geradores de senha de hoje, muitas vezes produzir cordas de 32-128 caracteres, mas quem sabe o que hashes serão utilizados nos próximos anos.

Answer 2

caracteres

Não-ASCII certamente fazer as coisas mais difíceis quando se trata de inserir a senha em dispositivos limitados (celulares, consoles etc.) - mas geralmente não impossível. Sem dúvida, se o usuário quiser fazer isso, você deve deixá-los. É fácil o suficiente para fazer uma coisa razoável e consistente - codificação em UTF-8 antes de hashing, por exemplo. Você só iria entrar em dificuldades se algum dispositivo de entrada enviou os personagens como uma composição (por exemplo, e + acento agudo em vez de "e aguda") - mas eu suspeito que wouldn' t acontecer na vida real. (Você poderia decompor tudo sozinho, mas isso seria um monte de problemas para ir para um caso extremo.)

Eu restringi-lo a impressão caracteres, no entanto. Colocar as abas, a alimentação de página etc em uma senha realmente é pedindo para ter problemas.

Answer 3

Não um especialista, mas eu odeio quando os personagens que eu escolher e não que bizarro são rejeitados. Então, acho que concordo com seu intestino.

Answer 4

Resposta curta: permitir que, tanto quanto o sistema de apoio ele pode suportar. Hoje em dia não há realmente nenhuma desculpa para não usar o suporte unicode completo para entrada de texto, e que inclui senhas. Eu não acho que você precisa se preocupar com problemas com caracteres, desde que eles são manipulados, literalmente, (mas eu não sou um profissional neste campo - cuidado com injeção de SQL).

Eu tenho uma implicância contra sites que impor restrições sobre senhas ... qualquer tipo de restrição. I como sites que irá dizer-lhe o quão forte sua senha é, e recomendo que você torná-lo mais forte, mas forçando o usuário a digitar pelo menos 8 caracteres, ou para exigir letras e números, etc. é frustrante simplesmente.

Se você precisa ter um tamanho de campo máxima (por exemplo, para armazenar em um banco de dados) tentar torná-lo grande o suficiente para qualquer coisa que as pessoas se digitar com a mão. Não há realmente nenhuma coisa como um grande demais campo de senha uma vez que há sempre a possibilidade de usar, uma senha forte gerada automatizado, mas de 64 a 128 caracteres certamente suficiente.

Answer 5

Fundamentalmente, a maioria da classe unicode de caracteres deve ser permitido. Não saltar no entanto controlar caracteres (por exemplo, 0-31 além de espaço), a marca de ordem de byte (0xfffe e oxfeff). Além disso, você quer primeiro canonizar a representação para se livrar de problemas causados ??por representações diferentes. Você pode emitir avisos embora por personagens que parecem ser muito difícil de entrar, mas os usuários vão proteger contra que eles mesmos.

Answer 6

Lembre-se: Quando você está armazenando senhas, todas as senhas devem ser criptografadas com um algoritmo one-way como md5 de SHA1. Uma vez que estes algoritmos sempre deu números hexadecimais, você não precisa se preocupar com injeções de SQL ou qualquer coisa assim.

Assim, enquanto você pode MD5 ou SHA1 um personagem, ele deve ser aceito.

Answer 7

Se você está falando sobre prevenção de tipo SQL-injeção de ataques, é provavelmente uma idéia melhor para se certificar de seu código faz o que é suposto fazer, em vez de confiar em restringir a entrada de modo que o problema se torna mais fácil.

Para caracteres não-ascii, eu não vejo isso como um problema mais difícil se a sua entrada pode ser corretamente representado como uma cadeia binária (e não como texto ), que é então passado para a sua função hash ou gerador de chaves, etc.

Answer 8

Adicionar outro voto para "permitir que o usuário incluir todos e quaisquer caracteres que sua interface lhes permite entrar". Eu nem Desautorizar guia ou controle caracteres. O software tem a capacidade de aceitar arbitrária strings de bytes e de hash-los, para aceitar cadeias de bytes arbitrários como senhas. Para fazer o contrário reduz o espaço que um atacante deve procurar em um de força bruta ou dicionário ataque.

(Claro, mesmo se você permitir tudo, 99% dos usuários ainda usam o nome de seu animal de estimação como a sua senha ...)

Answer 9

Finalmente, você pode ter que imprimir a senha clara em um e-mail confirmlation enviado aos seus usuários.

PS: pode considerar também codificação problemas no e-mail, se não é ascii padrão, é possível que um usuário não receberá o e-mail no formato adequado ou simplesmente não pode lê-lo em outro sistema (por exemplo, caracteres japoneses). devido a fontes não sendo instalado.

Tudo isso pesa os caracteres ASCII "imprimíveis" variam.