Hay una gran cantidad de estupideces cuando se trata de contraseñas en sitios web.
- Algunos tienen razones puramente técnicas (válidas o no, esa es otra pregunta, pero casi todas no lo son):
Su contraseña debe tener cuatro caracteres y solo tener dígitos.
(Al limitar una contraseña al rango 0001 .. 9999, simplemente puede almacenarlos como un número, texto sin formato, en la base de datos)
- Otros se explican por algunos pensamientos erróneos de que harán que las contraseñas sean más seguras :
Su contraseña debe comenzar con una letra mayúscula y terminar con un dígito.
(Al hacer esto, el desarrollador, o el gerente, asumió que esto realmente obligará a los usuarios a elegir una contraseña segura, mientras que la regla como "Su contraseña debe contener un mínimo de 6 caracteres y contener al menos una letra mayúscula, minúscula y un dígito "mágicamente no podrá hacerlo)
- Otros, finalmente, se explican por el hecho de que las contraseñas se almacenan en texto plano , y hay algunas ambigüedades sobre cómo se almacenan, procesan o recuperan, y no hay tiempo para probarlas de forma unitaria.
Su contraseña contiene un caracter inválido é.
o,
Su contraseña y$₯46¥*A'xD<7&฿=ᴙcN&sF5_Ở!dcontiene algunos caracteres inválidos. Use caracteres del alfabeto latino y dígitos solamente.
o,
Su contraseña no puede contener espacios en blanco.
En los tres casos, el desarrollador solo se aseguró de que las contraseñas como esta se almacenarán correctamente.
En el primer caso, ¿qué pasa si ése transformará %C3%A9cuando se envíe? ¿O qué pasa si la base de datos se almacenará éincorrectamente?
En el segundo caso, ¿qué pasa si PHP (¿por qué PHP?) No puede tratar con Unicode y hace algo terrible al recibir una contraseña como esta? ¿Qué pasa si el <personaje causa problemas? ¿Qué sucede si el &carácter se interpreta como un separador en una URL (suponiendo que por alguna razón, la contraseña se envía a través de GET en lugar de POST)? ¿Qué pasa si 'es interpretado por la base de datos, porque, adivina qué, no tenemos idea de qué es la inyección SQL y cómo evitarla? ¿O qué 'pasa si se transforma en \'?
En el tercer caso, ¿qué pasa si PHP (¿otra vez?) Recorta los espacios en blanco en algunos casos y no en otros? ¿Qué sucede si los administradores (que sorprendentemente tienen acceso a las contraseñas de los usuarios en texto sin formato) se pierden porque solo ven un espacio en blanco, mientras que el usuario ha establecido tres espacios en blanco consecutivos ?
En los tres casos, esas ambigüedades se resuelven fácilmente mediante pruebas , especialmente pruebas unitarias. Pero en una gran cantidad de proyectos, no hay pruebas en absoluto , y no hay tiempo para probar (pero aún hay mucho tiempo para depurar más tarde).
Esto significa que si el desarrollador trata de pensar en las posibles consecuencias de permitir espacios , caracteres unicode o cualquier otro carácter fuera de ASCII 48..57 ∪ 65..90 ∪ 97..122 (dígitos, letras minúsculas, letras mayúsculas) , la forma más fácil, cuando las pruebas no son posibles, es prohibirlas .
En mi opinión, esta es la única razón para prohibir espacios. Yannis Rizos dio otra razón relacionada con UX. Si bien es una razón plausible en teoría, no funciona en absoluto en la práctica: los sitios web creados por personas que realmente se preocupan por UX no arreglan reglas estúpidas de contraseña. En cambio, los sitios web donde el espacio en blanco está realmente prohibido están en su mayor parte realizados por personas que nunca escucharon sobre UX . Esto es especialmente cierto ya que prohibir cualquier carácter es realmente molesto desde el punto de vista de UX, como cualquier restricción relacionada con la contraseña, incluidas las útiles, como el número mínimo de caracteres.