¿Por qué no permitir caracteres especiales en una contraseña?

Una explicación que no he visto aquí es que muchas instituciones financieras están estrechamente integradas con los sistemas más antiguos y están atadas a las limitaciones de esos sistemas.

La ironía de esto es que he visto sistemas que fueron diseñados para ser compatibles con sistemas más antiguos, pero ahora los sistemas más antiguos ya no existen y la política aún debe existir para que sea compatible con el sistema más nuevo que fue creado para ser compatible con los sistemas más antiguos. sistema.

(la lección aquí es que si tiene que ser compatible con un sistema antiguo, permita una eliminación futura de esas limitaciones).

¿Qué pasa con el costo de soporte? Digamos que permitimos que cualquier persona cree una contraseña consiste en € chars. Hurra, podemos usar caracteres especiales en nuestras contraseñas. Pero espere, ¿cómo podemos escribir esa contraseña si queremos obtener el acceso a nuestro banco desde el teléfono móvil? Es más fácil escribir € desde nuestro teclado que desde el teléfono móvil.

¿Qué pasa con las vacaciones? Estamos en el Reino Unido, que solo acceden al teclado del Reino Unido. En lugar de € podemos escribir fácilmente £ . La palabra easily es muy importante aquí. Para algunos usuarios promedio, escribir esos caracteres para el "nuevo" teclado podría ser un problema. ¿Cómo intentará resolverlo? Probablemente llamará al servicio de asistencia bancaria para pedirles que cambien su contraseña o pedirle a why the € character dissapeared from his keyboard .

Esto se puede justificar (débilmente) como una medida de defensa en profundidad: si hay una inyección u otro error de interpretación de datos, la limitación del conjunto de caracteres de la contraseña y la longitud pueden evitar que sea explotable. También simplifica algo la implementación, ya que si solo tratan con caracteres ASCII de 7 bits, el manejo de cadenas de caracteres Unicode y multibyte es irrelevante, y las implementaciones más simples son, como regla, menos propensas a contener errores.

Sin embargo, evaluar esta disminución del riesgo frente al mayor riesgo debido a la menor calidad de la contraseña no es simple: esperaría que a medida que aumente la cantidad de usuarios de un sistema, también aumentara la cantidad de contraseñas que podrían estar comprometidas, haciendo una inversión En levantar esas restricciones más vale la pena. Dicho todo esto, las contraseñas de la mayoría de los usuarios serán terribles incluso si el campo no tiene restricciones.

Mi opinión es que la política existe para todos los campos ingresados por el usuario y la misma política de entrada del usuario (sin caracteres especiales) se aplicó a los campos, incluidas las contraseñas, para simplificar. O, en algún momento, algún banco no tenía contraseñas de hash y tuvo un ataque de SQLi a través de su campo de contraseña, y se decidió una política que las contraseñas no pueden tener caracteres especiales (y se olvidó el motivo de la política una vez que se introdujo el hashing). / p>

Definitivamente, existe un beneficio de seguridad al no permitir caracteres especiales en otros campos ingresados por el usuario que no están hash y pueden usarse para varios ataques como SQLi o XSS (en un administrador de un banco que mira una cuenta). Sin embargo, estas amenazas generalmente se resuelven utilizando siempre parámetros enlazados en SQL y siempre limpiando la entrada del usuario antes de mostrar / guardar en db.

Mi otra conjetura es que quieren tener reglas personalizadas que puedan ser diferentes a las de otros lugares, por lo que no puede reutilizar fácilmente su contraseña segura estándar (que puede perderse), y tiene que encontrar algo único para su sitio.

EDITAR: Pensándolo mejor, dependiendo del idioma, puedo pensar en al menos tres caracteres ASCII especiales que deberían estar universalmente prohibidos / eliminados, ya que permitirlos solo tienta al destino. Específicamente: \r (null - ascii 0), ya que se usa habitualmente para indicar el final de la cadena en los lenguajes de estilo C (posiblemente los usuarios deben modificar la memoria después del final de la cadena). También los retornos de carro y los avances de línea \n (ascii 13) y \r\n (ascii 10), ya que estos son a menudo dependientes del sistema si los saltos de línea son \n o ,./<>?;':"[]{}\|!@#$%^&*(-=_+ y eso hace inevitable que solo puedo iniciar sesión Desde Windows no es mi maquina / linux. De hecho, parece bastante razonable permitir solo ascii imprimible (32-126) y prohibir el ASCII no imprimible 0-31 y 127.

Pero si por caracteres especiales te refieres a caracteres Unicode, no a ASCII (como 2b 41 38 41 2d , parece razonable que la implementación de múltiples sistemas operativos / teclados / navegadores no permita caracteres especiales. Imagina que tu contraseña tiene una letra minúscula). Era que el pi griego (π) que es el punto de código 0x3c0 o el pi copiado en minúscula (tic) que es el punto de código 0x2ca1: solo funcionará uno y este tipo de problema de caracteres similares con diferentes puntos de código existirá en Unicode. en bits no podrá igualar los dos π, por lo que si intenta iniciar sesión en diferentes lugares, puede ingresar diferentes caracteres.

De manera similar, aunque este problema es uno que el programador puede controlar e intentar hacer en gran medida, permitiendo que los caracteres Unicode creen problemas de codificación. Es decir, para sus caracteres ascii básicos, todo está representado en un número de un byte. Sin embargo, hay un montón de diferentes esquemas para codificar Unicode. Es UTF-7, UTF-8, UTF-16, UTF-32, Latin-1 (iso-8859-1), codificación Latin-N, y (para algunas codificaciones) cuál es el orden de los bytes (endian o little endian) ? El punto de código Unicode para pi (0x3c0) se representaría como bytes CF 80 en UTF-7, FF FE c0 03 en UTF-8, FF FE 00 00 c0 03 00 00 en UTF-16 y A1 en UTF-32. No podría representar pi en Latín-1 (solo tiene 95 caracteres imprimibles adicionales), pero si tenía un ¡ĄĦЁ‘ก”Ḃ en su contraseña y estaba en diferentes codificaciones, es posible que tenga que representarlo de cualquiera de los siguientes caracteres %code% (que en algunos Latin-N pueden estar a A1).

Sí, la página web puede tener un conjunto de caracteres definido, pero los usuarios pueden anular el conjunto de caracteres en una página en su navegador o pueden copiar y pegar datos de otros lugares en una codificación diferente. Al final del día, puede ser más simple simplemente prohibir esos caracteres.

Como generalización, aquí están las razones más comunes por las que las instituciones financieras restringen la complejidad de los conjuntos de caracteres y la longitud.

(1) Los servicios web son sistemas de front-end para aplicaciones de mainframe heredadas, que a menudo tienen una limitación de ocho caracteres formada solo por números y minúsculas de mayúsculas y minúsculas. No hay "caracteres especiales". Curiosamente esta es la limitación más común. +1 a Mark Burnett arriba.

(2) No son hash de las contraseñas, por lo que no pueden simplemente almacenar una cadena numérica de longitud fija (es decir, la salida de hash - 32 bytes de SHA256 (contraseña)). Como tales, tienen que preocuparse por limitar el tamaño de la entrada.

(3) El vector de amenaza de inyección SQL es solo un problema de contraseña si las contraseñas se almacenan como texto sin cifrar. Muchas organizaciones y otras pierden el tiempo preocupándose por escapar de los caracteres de la contraseña, cuando el problema se resuelve de inmediato almacenando una contraseña con hash (idealmente salted y estirada usando algo como PBKDF2 ).

Además de favorecer la simple atención al cliente, la contraseña restablece la seguridad SUPERIOR, no hay ninguna razón aceptable que yo sepa para transmitir una contraseña de usuario en texto claro fuera del dispositivo del usuario. Usted no quiere la responsabilidad, así que nunca los acepte. Para eso están los hash criptográficos.

Aquí hay una excelente publicación de blog que resume algunas de las mejores prácticas e incluye ejemplos de código. enlace

En realidad, le pregunté a una tienda virtual grande (bol.com, no estoy seguro de si son internacionales).

Su consejo es usar una contraseña segura, cambiarla con frecuencia, usar letras y números, que sea larga, y tal vez algunas otras cosas que olvidé. De todos modos, sigue el consejo habitual de que nadie . Pero parece que les importa la política de contraseñas.

Sin embargo, no permiten la mayoría de los caracteres especiales, y la longitud máxima de la contraseña es de 12 caracteres. Al preguntar, me dijeron que, de lo contrario, demasiadas personas se pondrían en contacto con el servicio de asistencia.

Cuando les devolví el correo para preguntar qué "¿Olvidó su contraseña?" la función era para, no tengo respuesta ...

Entonces, para los bancos, donde no es posible restablecer la contraseña por correo electrónico, supongo que los costos de soporte son realmente la razón (como lo sugieren otros). Para cualquier otro sitio web como este bol.com, desconfiaría en gran medida de que tengan sus contraseñas. Debería usar una contraseña más exclusiva allí, si la base de datos pierde su contraseña será conocida.

Limitar el conjunto de caracteres a caracteres alfanuméricos limita la probabilidad de que un script o un exploit supere la etapa de validación de entrada.

El usuario siempre puede mejorar su seguridad utilizando contraseñas más largas, pero la aplicación debe tener una lista blanca específica para ayudar a prevenir ataques.

Puedo intentar dar mi opinión del problema anterior como diseñador de interfaz de UI y no como programador: el punto clave aquí es que el requisito de inicio de sesión es en parte un problema de diseño de interfaz de UI y no un problema de programación solamente.

Hay un excelente libro "Apress - Diseño de interfaz de usuario para programadores" que muestra un problema análogo relacionado con el tamaño de las ventanas, que publicaré a continuación:

  

Aquí hay un patrón de pensamiento común del programador: solo hay tres   números: 0, 1, y n. Si se permite n, todas las n son igualmente probables.   Este patrón de pensamiento proviene de la antigua convención de codificación (probablemente   inteligente) que no debería tener ninguna constante numérica en su código   excepto 0 y 1.

Ahora, el pensamiento anterior es correcto en un problema de solo programación, pero en lo que concierne a las interfaces de usuario y especialmente a las ventanas, no lo es

  

Pero no es cierto. Como resultado, no es igualmente probable. Existen   muchas buenas razones por las que podría querer una ventana exactamente en la parte superior de   La pantalla (maximiza la pantalla de bienes raíces), pero realmente no hay   cualquier razón para dejar dos píxeles entre la parte superior de la pantalla y la   parte superior de la ventana. Entonces, en realidad, 0 es mucho más probable que 2.

Ahora que estamos abordando nuestro problema, teóricamente todos los caracteres deberían ser igualmente probables e igualmente permitidos desde un punto de vista de programación y formal, sin embargo, aquí también estamos en una instancia de problema de interfaz de interfaz de usuario y debemos ser conscientes de ello y dar la información correcta. peso para ello.

Así que parafrasearé una respuesta del hilo de arriba que, en mi opinión, es correcta:

  

Digamos que permitimos que cualquiera creara contraseñas que contienen el €   carbonizarse. Hurra, podemos usar caracteres especiales en nuestras contraseñas.   Pero espere, ¿cómo podemos escribir esa contraseña si queremos obtenerla?   ¿Acceso a nuestro banco desde el teléfono móvil? Es más fácil escribir €   desde nuestro teclado que desde el teléfono móvil.

Ese es el punto principal desde el punto de vista de la usabilidad y no deberíamos culpar al usuario si se da cuenta algunos años más tarde con un teléfono inteligente cuando años antes ni siquiera existían, que usó un personaje que debería tener. evitar.

¡Es nuestra obligación pensar en este tipo de problemas y dejar que el usuario lo evite!

Un poco tarde para la fiesta. Hace poco leí que la razón de esto es que para muchos bancos, el valor de la mayor seguridad de permitir esos caracteres se ve compensado por el costo de implementación y el costo de soporte de tratar con clientes que no pueden Recuerda sus contraseñas.

No estoy diciendo que sea una buena razón, pero así es como interpreté lo que leo.

enlace