Por que determinados sites evitam espaços nas senhas?


16

Parece menos comum em sites mais novos, mas muitos sites em que preciso de uma conta (como para pagar contas etc.) me impedem de criar uma senha com espaços. Isso só torna as coisas mais difíceis de lembrar , e eu não conheço nenhuma restrição de banco de dados ou programação sobre espaços em senhas, criptografadas ou (pelo contrário, se não for o caso). Por que, então, a barra de espaço é tão comumente discriminada quando se trata de se inscrever em um site?


Alguns sites podem usar o Logon único, supondo que o SSO exija senhas que não estejam em branco (embora não tenha certeza)!
NoChance

1
O que realmente me assusta é que os sites especificamente não permitem a citação única. Que possível motivo você poderia ter, além de habilitar "insert into USERS (..., password) values (..., '" + $POST['password'] + "');" : -S
Christian Klauser

Deveria ter ido para a segurança, não para programadores. Isso provavelmente já existe lá.
Dan McGrath

Respostas:


20

Há uma enorme quantidade de estupidez quando se trata de senhas em sites.

  • Alguns têm razões puramente técnicas (válidas ou não, essa é outra questão, mas quase todas elas não são):

Sua senha deve ter quatro caracteres e ter apenas dígitos.

(Limitando uma senha ao intervalo 0001 .. 9999, você pode simplesmente armazená-las como um número, texto sem formatação, no banco de dados)

  • Outros são explicados por alguns pensamentos errôneos de que eles tornarão as senhas mais seguras :

Sua senha deve começar com uma letra maiúscula e terminar com um dígito.

(Ao fazer isso, o desenvolvedor ou o gerente presumiu que isso forçaria os usuários a escolher uma senha segura, enquanto a regra "Sua senha deve conter no mínimo 6 caracteres e conter pelo menos uma letra maiúscula, minúscula e uma dígito "falhará magicamente em fazê-lo)

  • Outros, finalmente, são explicados pelo fato de que as senhas são armazenadas em texto sem formatação , e existem algumas ambiguidades sobre como elas são armazenadas, processadas ou recuperadas, e não há tempo para testá-las.

Sua senha contém um caractere inválido é.

ou,

Sua senha y$₯46¥*A'xD<7&฿=ᴙcN&sF5_Ở!dcontém alguns caracteres inválidos. Use caracteres do alfabeto latino e apenas dígitos.

ou,

Sua senha não pode conter caracteres em branco.

Nos três casos, o desenvolvedor apenas garantiu que senhas como essa sejam armazenadas corretamente.

  • No primeiro caso, e se éserá transformado %C3%A9quando enviado? Ou, e se o banco de dados for armazenado éincorretamente?

  • No segundo caso, e se o PHP (por que PHP?) Não puder lidar com unicode e fizer algo terrível ao receber uma senha como esta? E se o <personagem causar problemas? E se o &caractere for interpretado como um separador em uma URL (supondo que, por algum motivo, a senha esteja sendo enviada por meio de GET em vez de POST)? E se 'for interpretado pelo banco de dados, porque, adivinhe, não temos idéia do que é a injeção de SQL e como evitá-la? Ou o que se 'transforma \'?

  • No terceiro caso, e se o PHP (de novo?) Apara o espaço em branco em alguns casos e não em outros? E se os administradores (que surpreendentemente têm acesso a senhas de usuários em texto sem formatação) forem perdidos porque veem apenas um espaço em branco, enquanto o usuário definiu três espaços em branco consecutivos ?

Nos três casos, essas ambiguidades são facilmente resolvidas por meio de testes , especialmente testes de unidade. Mas em uma enorme quantidade de projetos, não há nenhum teste e não há tempo para testar (mas ainda há muito tempo para depurar mais tarde).

Isso significa que, se o desenvolvedor tenta pensar nas possíveis consequências de permitir espaços , caracteres unicode ou qualquer caractere fora do ASCII 48..57 ∪ 65..90 ∪ 97..122 (dígitos, letras minúsculas, letras maiúsculas) , a maneira mais fácil, quando o teste não é possível, é apenas proibi-los .

Na minha opinião, esse é o único motivo para proibir espaços. Yannis Rizos deu outro motivo relacionado ao UX. Embora seja uma razão plausível na teoria, na prática não funciona: sites criados por pessoas que realmente se preocupam com o UX não corrigem regras estúpidas de senha. Em vez disso, os sites onde o espaço em branco é realmente proibido são em grande parte criados por pessoas que nunca ouviram falar do UX . Isso é especialmente verdadeiro, pois a proibição de qualquer caractere é realmente irritante do ponto de vista do UX, como qualquer restrição relacionada à senha, incluindo as úteis, como o número mínimo de caracteres.


Sem mencionar que, quando você elimina espaços, você elimina várias senhas longas fáceis de lembrar (e o comprimento se mostrou mais eficaz do que a complexidade contra o cracking) e incentiva os usuários a adotarem senhas sem sentido que são muito menos memoráveis ​​do que uma série longa de espaços.
Lèse majesté

1
Concordo com a maior parte do que leio ouvir, mas tenho muita dificuldade em digerir a afirmação "da maneira mais fácil, quando o teste não é possível ...". Teste não é possível ??? Quem concorda com um projeto em que isso ocorre: a estupidez é maximizada com eficiência ... Sim, eu sei que isso acontece: - |
Thomas

@ Thomas: essa é a diferença entre teoria e conhecimento em geral e prática, com sua ignorância geral e restrições de tempo, onde muitas pessoas não querem perder tempo testando, ignorando que gastarão pelo menos duas vezes mais tarde a depuração.
Arseni Mourzenko

Pode ser razoável exigir que os usuários definam uma senha que consiste apenas em dígitos, se a mesma senha for necessária para itens como acesso telefônico automatizado, mas essa senha não deve ser a principal credencial de autenticação para acesso baseado em computador.
supercat

3

A resposta é História

Parece que esquecemos que a base de tudo isso vem de uma época em que o armazenamento não era efetivamente livre (em disco ou na memória) quando nossa capacidade de gerenciar todas essas coisas era um pouco menor do que é agora e igualmente a capacidade dos sistemas automatizados tentar quebrar o mesmo também era um pouco menor.

Existem muitas reclamações sobre senhas baseadas no que sabemos agora e no que podemos fazer agora, mas o simples fato é que estamos lidando com uma combinação de pensamento e sistemas legados.

Agora deve haver restrições em novos sistemas ? Eu espero que não - muito menos razão agora


Você está dizendo que havia restrições tecnológicas com espaços nas senhas que não existiam antes? Que papel o armazenamento desempenhou exatamente nisso?
Ian Hunter

1
Estou sugerindo que os limites tecnológicos e restrições externas menos complexas (e possivelmente o uso de "aparar") significavam que as pessoas pensavam diferentemente sobre o que seria apropriado e permitido. Você pode colocar limites nas senhas para garantir que elas sejam memoráveis, pois redefini-las é mais difícil. Você pode não criptografá-los porque simplesmente chegar a um lugar onde você pode lê-los é (na época) relativamente difícil (e, em qualquer caso, os sistemas não são acessíveis pelo mundo exterior). Momentos diferentes, completamente diferentes processos de pensamento, que deixaram um legado
Murph

2

IMHO, é totalmente tolo qualquer site / aplicativo que use hash e / ou salga modernos para armazenar senhas e não permitir espaços nas senhas. Porém, alguns sistemas legados (leia sobre isso em algum lugar) ainda transmitem senhas em texto simples - portanto, não permitir espaços lá pode fazer sentido. Além disso, alguns aplicativos podem "retirar" todas as entradas de string que recebem. Portanto, uma senha que comece ou termine com um espaço não será boa (é claro, isso foi inventado em excesso, mas você pode imaginar o que não pode acontecer com quase qualquer pessoa inventando seu próprio site). Não há nada "ruim" em permitir espaços nas senhas - como você ressalta, os bancos de dados não desaprovam os hashes ou as versões de texto sem formatação.

Na verdade, a maioria dos meus amigos do Windows não sabe que podem usar espaços em suas senhas - então, talvez, de acordo com a resposta de Tim Medora, os proprietários de sites não desejem se arriscar com lamahs (desculpe) ou talvez alguns deles tenham equívocos e / ou ignoram as vantagens que os espaços podem oferecer.


1
Eu prefiro remover espaços à esquerda / à esquerda das senhas porque elas tendem a causar problemas, mas isso não é motivo para desautorizá-las - elas serão despojadas na configuração e no teste, sem problemas.
Loren Pechtel

E quais são exatamente os "problemas"? Eu tenho enfatizado na resposta que os espaços DEVEM ser permitidos. "Eles serão despojados tanto na configuração quanto no teste" - Qual é o objetivo, então? então "1 4m 1337" e "1 4am 1337" ambos combinam o mesmo valor (na verdade, há um número infinito de possibilidades na teoria).
yati sagade

What's the point then?O ponto secundário é que a senha é de menos entropia conforme o usuário pretendeu. E alguns sistemas cortam os vars GET / POST por padrão, uma mudança (improvável) nesse comportamento levará a problemas mais sérios.
yannis

@ Yati sagade: Eu não estou falando sobre remover espaços internos. Estou falando de espaços iniciais e finais - as pessoas não percebem que o espaço existe e isso causa falhas no login. Da mesma forma, se você vir uma senha com todas as letras maiúsculas em maiúsculas e minúsculas, provavelmente alguém que não percebeu que a letra maiúscula estava ativada.
Loren Pechtel

-1

Isso é feito pela mesma razão que muitos sites não permitem hífens, apóstrofos ou letras não ASCII nos nomes, mesmo que sejam práticas muito comuns, mesmo dentro dos EUA, e exija mais trabalho para desautorizar esses caracteres do que simplesmente permitir eles.

Isso também é feito pela mesma razão que os filtros de palavras de muitos sites não permitem que você use palavras como "arrogante", "retardador" ou mesmo "acumular" (embora muitas insultos raciais comuns estejam perfeitamente bem).

É porque muitos desenvolvedores aparentemente estão completamente sem senso comum, ou pelo menos têm uma imaginação muito limitada ao considerar possíveis entradas e cenários do usuário. Uma pequena porcentagem deles pode estar trabalhando com informações falsas (que excluir caracteres não alfanuméricos é de alguma forma uma prática padrão ou que o algoritmo de hash ou o método de armazenamento não pode manipular espaços ou caracteres especiais). Outros podem simplesmente ser preguiçosos - eles estão preocupados com problemas de conjunto de caracteres, então eles simplesmente restringem as entradas a um espaço mínimo de caracteres. E pode haver quem esteja exercendo validação / saneamento de entrada excessivamente zeloso por causa da paranóia devido à falta de entendimento de ameaças reais.


Que motivo você teria para empregar uma lista de permissões além de aplicar uma codificação de caracteres específica? O fato de restringir caracteres arbitrários não conferir benefícios enquanto enfraquece as senhas que os usuários escolhem é o que eu baseio essa opinião. Todos os exemplos que dei são sintomas de desenvolvedores que não pensam nas opções de design com cuidado.
Lèse majesté
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.