¿Por qué ciertos sitios evitan espacios en las contraseñas?

16

Parece menos común con los sitios web más nuevos, pero muchos sitios web en los que necesito una cuenta (como para pagar facturas, etc.) me impiden crear una contraseña con espacios en ella. Esto solo hace que las cosas sean más difíciles de recordar , y soy consciente de que no hay restricciones en la base de datos o en la programación de espacios en las contraseñas, encriptadas o (Dios no lo quiera) de otra manera. ¿Por qué, entonces, la barra espaciadora es tan comúnmente discriminada cuando se trata de registrarse en un sitio?

Ian Hunter
fuente
Es posible que algunos sitios usen Single Sign On, suponiendo que SSO requiere contraseñas que no estén en blanco (aunque no estoy seguro).
NoChance
1
Lo que realmente me asusta es cuando los sitios rechazan específicamente la cita simple. ¿Qué posible razón podría tener, aparte de habilitar "insert into USERS (..., password) values (..., '" + $POST['password'] + "');" : -S
Christian Klauser
Debería haber ido a la seguridad, no a los programadores. Sin embargo, esto probablemente ya existe allí.
Dan McGrath

Respuestas:

20

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.

Arseni Mourzenko
fuente
Sin mencionar que cuando eliminas espacios, estás eliminando un montón de contraseñas largas fáciles de recordar (y se ha demostrado que la longitud es más efectiva que la complejidad contra las grietas) y estás alentando a los usuarios a adoptar contraseñas galimatías que son mucho menos memorables que una serie larga de espacios.
Lèse majesté
1
Estoy de acuerdo con la mayoría de lo que leo, pero me cuesta mucho digerir la declaración "de la manera más fácil, cuando las pruebas no son posibles ...". ¿Pruebas no posibles? Cualquiera que acepte un proyecto donde eso ocurre: la estupidez maximiza eficientemente ... Sí, sé que sucede: - |
Thomas
@Thomas: esta es la diferencia entre la teoría y el conocimiento en general y la práctica con su ignorancia general y las limitaciones de tiempo, donde muchas personas no quieren perder el tiempo probando, ignorando que pasarán al menos dos veces más tarde depurando.
Arseni Mourzenko
Puede ser razonable exigir que los usuarios definan un código de acceso que consiste solo en dígitos si el mismo código de acceso puede ser necesario para cosas como el acceso telefónico automatizado, pero dicho código de acceso no debería ser la credencial de autenticación principal para el acceso basado en computadora.
supercat
3

La respuesta es historia

Parece que olvidamos que la base de muchas cosas proviene de un momento en que el almacenamiento no era efectivamente libre (en el disco o en la memoria) cuando nuestra capacidad para administrar todas estas cosas era algo menor de lo que es ahora e igualmente la capacidad de los sistemas automatizados intentar descifrarlo también fue algo menos.

Hay muchas críticas sobre las contraseñas basadas en lo que sabemos ahora y lo que podemos hacer ahora, pero el hecho simple es que a menudo estamos lidiando con una combinación de pensamiento heredado y sistemas heredados.

¿Debería haber restricciones en los nuevos sistemas ahora ? Espero que no, mucho menos razón ahora

Murph
fuente
¿Estás diciendo que no había restricciones tecnológicas con espacios en las contraseñas que no había antes? ¿Qué papel jugó exactamente el almacenamiento en eso?
Ian Hunter
1
Estoy sugiriendo que los límites tecnológicos y las restricciones externas menos complejas (y posiblemente el uso de "recorte") significaron que las personas pensaban de manera diferente sobre lo que sería apropiado y permisible. Puede poner límites a las contraseñas para asegurarse de que sean memorables porque restablecerlas es más difícil. Es posible que no los cifre porque simplemente llegar a un lugar donde puede leerlos es (en ese momento) relativamente difícil (y, en cualquier caso, los sistemas no son accesibles desde el mundo exterior). Diferentes momentos, procesos de pensamiento completamente diferentes que han dejado un legado
Murph
2

En mi humilde opinión, es completamente tonto de cualquier sitio / aplicación que utiliza hashing moderno y / o salazón para almacenar contraseñas para no permitir espacios en las contraseñas. Pero, algunos sistemas heredados (lea sobre esto en alguna parte) todavía pasan contraseñas en texto sin formato, por lo que no permitir espacios allí puede tener sentido. Además, algunas aplicaciones pueden "quitar" todas las entradas de cadena que reciben. Por lo tanto, una contraseña que comience o termine con un espacio no va a ser buena (por supuesto, eso fue demasiado inventado, pero puedes imaginar lo que no puede pasar con casi cualquier persona que tenga su propio sitio). No hay nada "malo" en permitir espacios en las contraseñas: como usted señala, los DB no permitirán los hashes o las versiones de texto sin formato.

En realidad, la mayoría de mis amigos de Windows no saben que pueden usar espacios en sus contraseñas. Entonces, tal vez, según la respuesta de Tim Medora, los propietarios del sitio no quieren arriesgarse con lamahs (perdón por eso) o tal vez algunos de ellos tienen conceptos erróneos y / o ignoran las ventajas que los espacios pueden proporcionar.

Yati Sagade
fuente
1
Prefiero eliminar los espacios iniciales / finales de las contraseñas porque tienden a causar problemas, pero esa no es razón para no permitirlos: simplemente se eliminarán tanto en la configuración como en las pruebas, no hay problema.
Loren Pechtel
¿Y cuáles son exactamente los "problemas"? He estado enfatizando en la respuesta que los espacios DEBEN SER permitidos. "Serán despojados tanto en la configuración como en las pruebas" - ¿Cuál es el punto entonces? entonces "1 4m 1337" y "1 4am 1337" ambos hash al mismo valor (en realidad, hay un número infinito de posibilidades en teoría).
yati sagade
What's the point then?El punto menor es que la contraseña tiene menos entropía como lo pretendía el usuario. Y algunos sistemas recortan las variables GET / POST por defecto, un cambio (poco probable) en ese comportamiento dará lugar a problemas más serios.
Yannis
@Yati sagade: NO estoy hablando de desnudar los espacios internos. Estoy hablando de espacios iniciales y finales: las personas no se dan cuenta de que el espacio está allí y causa fallas de inicio de sesión. Del mismo modo, si ve una contraseña con mayúsculas, póngala en minúsculas, probablemente sea alguien que no se dio cuenta de que el bloqueo de mayúsculas estaba activado.
Loren Pechtel
-1

Se hace por la misma razón por la que muchos sitios no permiten guiones, apóstrofes o letras no ASCII en los nombres, a pesar de que estas son prácticas muy comunes incluso dentro de los EE. UU. Y requiere más trabajo para no permitir estos caracteres que simplemente permitir ellos.

También se hace por la misma razón por la que los filtros de palabras de muchos sitios no le permiten usar palabras como "engreído", "retardante" o incluso "acumular" (aunque muchos insultos raciales comunes están perfectamente bien).

Esto se debe a que muchos desarrolladores aparentemente carecen por completo de sentido común, o al menos tienen una imaginación muy limitada al considerar las posibles entradas y escenarios de los usuarios. Un pequeño porcentaje de ellos puede estar trabajando con información falsa (que excluir caracteres no alfanuméricos es de alguna manera una práctica estándar, o que el algoritmo de hash o método de almacenamiento no puede manejar espacios o caracteres especiales). Otros pueden ser simplemente perezosos: están preocupados por los problemas del juego de caracteres, por lo que simplemente restringen las entradas a un espacio mínimo de caracteres. Y luego puede haber quienes están ejerciendo una validación / sanidad de entrada excesivamente celosa debido a la paranoia debido a la falta de comprensión de las amenazas reales.

Lèse majesté
fuente
¿Qué razón tendría para emplear una lista blanca más allá de aplicar una codificación de caracteres en particular? El hecho de que restringir los caracteres arbitrarios no confiere beneficios al tiempo que debilita las contraseñas que eligen los usuarios es en lo que baso esta opinión. Todos los ejemplos que di son síntomas de desarrolladores que no piensan en las opciones de diseño con suficiente cuidado.
Lèse majesté