¿Indica que un sistema de contraseña incorrecta no permite ciertos caracteres en las contraseñas?

Prohibir ciertos caracteres no indica en sí mismo que el sistema contraseña está dañado, pero es una mala señal, y sugiere que el desarrollador tiene poca confianza o una mala comprensión de su sistema de procesamiento de datos . La explicación más probable es que el desarrollador teme algún tipo de ataque de inyección: inyección SQL, secuencias de comandos entre sitios o algo por el estilo. Sin embargo, las barras diagonales y los espacios son los caracteres más probables aquí, pero tal vez también estén prohibidos ' , < y > , o tal vez estén recodificados (pero, ¿por qué no recodificar / y el espacio?).

La contraseña debe enviarse en texto sin cifrar al servidor y debe estar oculta allí, o al menos parte de la codificación de la contraseña debe estar oculta en el servidor (si la contraseña se halle en el cliente, la clave de hash de la contraseña sería efectivamente la contraseña, que no sería buena si un intruso la hubiera obtenido).

Podría darse el caso de que la infraestructura web sea mala (llena de inyección SQL, XSS, etc.), pero el código de hashing de contraseña invoca la función de biblioteca correcta y almacena un hash lento y con sal. O podría ser el caso de que la contraseña se almacene en algún pseudo-base de datos de formato extraño y es por eso que ciertos caracteres están prohibidos.

También podría darse el caso de que este sea un requisito de la experiencia del usuario, que puede o no haber sido interpretado según lo previsto por el desarrollador. Algunos sitios restringen los caracteres especiales en las contraseñas para evitar que los usuarios elijan contraseñas que no podrán escribir fácilmente en algunos dispositivos. Dado que esto es para un juego, tal vez haya una interfaz dentro del juego que requiera que el usuario ingrese su contraseña, pero no permite espacios o barras (o barras invertidas, que también están prohibidas). Si ese es el caso, probablemente también deberían prohibir los caracteres que no son ASCII.

Mirando las instrucciones de recuperación de contraseña de League of Legends, aparece que no almacenan la contraseña en texto claro, sino que proporcionan un enlace de restablecimiento de contraseña estándar de la industria que se envía a la dirección de correo electrónico asociada a la cuenta. Un anuncio de seguridad menciona que la contraseña de la base de datos contiene "hashes de contraseña con sal", por lo que parecen saber cómo hacer las cosas correctamente. Al menos tienen algunos de los conceptos básicos correctos: la página a la que se enlazan explica sal, pero no menciona que un hash de contraseña debe ser lento. Aún así, dadas estas pistas, no estoy demasiado preocupado: probablemente no estén haciendo algo extremadamente malo (en el peor de los casos, están usando un hachís rápido pero salado). Sospecho que la explicación de las restricciones es una interfaz restringida para escribir una contraseña en alguna versión del juego.

Puede ponerse en contacto con los propietarios del sitio y preguntarles específicamente qué sucede con el requisito arbitrario. En realidad, pregúnteles específicamente qué algoritmo de hash de contraseña están usando para crear un resumen de su contraseña y cómo están calculando y almacenando la sal.

Tal vez estoy exagerando un poco, pero mi punto es que si su sistema es seguro porque es oscuro, entonces no lo es.

No utilizaría la misma contraseña para el sistema que usa para sus operaciones bancarias en línea, pero es un buen consejo en general (diferentes contraseñas para diferentes sitios).

Con respecto a la longitud máxima, los algoritmos de hashing primitivos aceptados como los algoritmos SHA no se preocupan por la longitud de entrada, y la longitud de salida de esas funciones es constante independientemente del tamaño de la entrada, si la entrada es de tres caracteres o Enciclopedia entera británica.

Si desea una contraseña de 100 caracteres, debería poder tener una.

Al limitar su contraseña a 16 caracteres, me dice (correcto o incorrecto) que probablemente están almacenando su contraseña de texto simple y que el campo en el que la almacenan tiene 16 caracteres.

EDITAR: O podría ser una señal de que están haciendo algo en la línea del antiguo algoritmo hash de contraseña de LanManager, usando tu contraseña, o partes de tu contraseña en dados, como claves para un cifrado simétrico como DES o AES para generar hashes de contraseña de tamaño fijo. Eso se podría hacer bien o mal. ¿Están usando sal en absoluto? ¿Prefieren un algoritmo hash rápido (NO es una buena señal si lo están) sobre los algoritmos diseñados para el hashing de contraseñas, como scrypt / bcrypt / pbkdf2? Etc.

Además, los espacios y las barras diagonales no son diferentes de otros caracteres, a menos que estén haciendo algo como usar el valor de contraseña para un nombre de archivo (tal vez un nombre de archivo temporal) o pasarlo incrustado en algo como SQL o JSON, en cuyo caso les preocuparía tener que escapar correctamente de esos valores en la cadena o romper su software.

Lo que deberían estar haciendo es manejar la contraseña como datos binarios, codificarla según sea necesario si tienen que pasarla de un componente a otro (por ejemplo, Base64), y nunca mantener la contraseña real no dañada Alrededor incluso en la RAM más tiempo del necesario, luego se almacena el hash En el caso de SHA-1 (teóricamente roto ahora), el hash tiene una longitud de 160 bits, aunque hay defensores de truncar el hash antes del almacenamiento (no estoy del todo seguro de que esté en ese campo, pero es probable que sea está bien y eso es un problema diferente).

La seguridad es difícil de hacer bien, a menudo se hace mal, a menudo se descuida o se trata a la ligera y este sistema suena frágil, para mí, además de todo eso. Creo que tienes razón para sospechar de ello.

Podría haber razones legítimas para restringir el conjunto de caracteres permitidos en las contraseñas. Por ejemplo, si la contraseña contenía un carácter que no era un carácter ASCII imprimible, entonces los problemas de codificación podrían causar que se rechace una contraseña correcta en algunas circunstancias.

Además, si un usuario en diferentes momentos necesita escribir la misma contraseña en diferentes distribuciones de teclado, entonces puede ser problemático utilizar caracteres que se ubican de manera diferente en esas distribuciones de teclado.

Un adversario podría ser capaz de averiguar qué usuarios se ven afectados por los problemas anteriores y de esa manera obtener algún conocimiento sobre qué caracteres han utilizado esos usuarios en su contraseña.

Restringir el conjunto de caracteres permitidos por las razones anteriores no tiene que debilitar la fortaleza de las contraseñas. Todo lo que tienes que hacer es hacer que la contraseña sea un poco más larga. (En el caso extremo, si dejó de permitir que todo el ASCII imprimible solo permita letras minúsculas, tendría que aumentar la longitud de la contraseña en un 40% para tener la misma entropía).

También hay malas razones para restringir el conjunto de caracteres permitidos. Por ejemplo, si un sistema restringe el conjunto de caracteres permitidos para evitar ataques de inyección de SQL, le informará sobre dos fallas de seguridad en el sistema. En primer lugar, no utiliza el escape adecuado para las consultas SQL. En segundo lugar, claramente no utiliza ningún hashing de contraseñas.

Para la longitud de la contraseña, una limitación puede ser una buena idea para evitar problemas en caso de que algún cliente esté aplicando limitaciones arbitrarias en los campos de entrada. Por ejemplo, si alguien pensó que era una buena idea usar un carácter con signo para indicar la longitud de un campo, eso no tendría más de 127 caracteres como máximo. He creado sistemas en los que apliqué una longitud máxima de 125 caracteres en las contraseñas como medida de precaución contra tales posibilidades (y posiblemente un par de errores off-by-one).

La imposición de una longitud máxima en las contraseñas reduce la seguridad si esa longitud máxima es demasiado corta. Debe comparar con las primitivas criptográficas simétricas que podría estar usando. Eso significa que debemos comparar con los tamaños de bloque y clave de cifrado de bloque, así como la salida de funciones hash. Eso significa que normalmente esperaríamos de 128 a 512 bits de seguridad de nuestras primitivas criptográficas. No permitir contraseñas que puedan coincidir con esos niveles de seguridad sería contraproducente. Dependiendo del conjunto de caracteres permitido, podría haber desde 4.7 (solo letras minúsculas) hasta 6.57 (todos los ASCII imprimibles) bits de entropía por carácter en una contraseña segura. Con un poco de matemática, vemos que si no permitimos al menos 20 caracteres, definitivamente establecemos el límite demasiado bajo, y si permitimos 109 caracteres, deberíamos estar muy seguros.

Es poco probable que un límite superior a 100 o 125 tenga un impacto real en la seguridad, porque es muy probable que ningún usuario suba tanto.

Cuando menciona una longitud máxima de 16 caracteres que se están aplicando, esto indica que es probable que los diseñadores hayan introducido ese límite por una mala razón. Una mala razón sería que la contraseña se almacena como texto sin formato y solo se asignaron 16 caracteres para el almacenamiento. Otra razón no tan mala sería que la contraseña se usa directamente como clave para una primitiva criptográfica (como AES).

La combinación de las dos restricciones (no permitir dos caracteres específicos y un límite máximo pequeño) es una señal de advertencia, ya que cada uno de ellos podría ser una elección debido a que las contraseñas se almacenan como texto sin formato.

Que el par específico de caracteres que decidieron rechazar es espacios y barras suena aterrador, porque las razones que podría imaginar para esos dos caracteres específicos que no se permiten es que podrían querer poner la contraseña de texto sin formato en un nombre de archivo o una línea de comando. Esperemos que solo sea cuestión de que me falte un poco de imaginación.

Por lo general, les digo a las personas que un sitio es importante: "Si hay caracteres prohibidos, están almacenando la contraseña en texto sin formato". No necesariamente cierto; sin embargo, lo siguiente se dice cuando el otro extremo intenta decir que no: "Al ver que los caracteres restringidos gritan al ingeniero 'Almaceno las contraseñas en texto sin formato' mucho más alto que cualquier documentación, y si no es así, la restricción se puede eliminar fácilmente". / p>

Debido a que esta presión general se aplica desde hace bastante tiempo, podemos suponer razonablemente que la mayoría de los restantes son los que realmente almacenan contraseñas en texto sin formato, y corregirlo es una forma barata de decir "no nosotros".

Upshot: si no puede molestarse en no restringir el campo de la contraseña, no es digno de mi confianza y me llevaré mi negocio a otra parte.