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_Ở!d
conté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%A9
quando 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.