¿Por qué los servicios de atención al cliente dicen que el uso de símbolos en una contraseña es inseguro?

Estas 'medidas de seguridad' no son para su seguridad, sino para las suyas.

Los símbolos como guiones, apóstrofes, signos de porcentaje, asteriscos, barras diagonales, puntos, etc. son útiles para los atacantes para realizar ataques de "inyección", como inyección de SQL, inyección de XPath, inyección de ruta de archivo, etc. Al bloquear esos caracteres, los propietarios del sitio esperan que le impidan atacar a sus servidores.

Probablemente deberían enfocarse más en el manejo adecuado de los datos, como el uso interno de SQL parametrizado y el escape de caracteres especiales, pero esta es una medida adicional que podría servir como un recurso provisional en caso de que tengan un error de codificación oculto en su sitio.

No puedo responder definitivamente 'por qué' hicieron esto. Tal vez tenían un auditor de seguridad que decía "usar un conjunto de caracteres en la lista blanca para la entrada del usuario y bloquear cualquier símbolo no alfanumérico". Tal vez el paquete web que compraron vino con esa restricción. Tal vez su vicepresidente de seguridad dijo "agregue algunas medidas visibles que den a nuestros clientes la impresión de que nos tomamos en serio la seguridad". ¿Quién sabe por qué?

  

La pregunta es por qué dijeron que es inseguro permitir símbolos en   contraseñas cuando los símbolos lo hacen más seguro?

Es más que probable que estuvieras tratando con alguien en el servicio al cliente que no tiene idea de por qué se implementaron ciertas reglas y que llegó a la conclusión, ya sea mediante el uso de esta excusa en el pasado y los resultados o inventándolos. su cabeza, que esto hará que la persona con la que están tratando no cuestione y simplemente haga.

Su explicación es correcta acerca de la complejidad de una contraseña cada vez más segura al agregar símbolos, letras, mayúsculas y minúsculas, y números.

Lo descartaría como un agente de servicio al cliente no capacitado que intenta facilitar el trabajo o esta persona sabe que la política es errónea y solo desea que esta conversación sea lo más breve posible.

Debido a que probablemente estén utilizando saneamiento de entrada en lugar de consultas parametrizadas y saneamiento de salida .

Si tuvieran consultas parametrizadas, esto no sería un problema. Si supieran cómo sanear su salida , esto no sería un problema.

Es más que probable que su código sea vulnerable a muchas otras cosas, como contrabando basado en unicode . Para muchos "desarrolladores seguros", el saneamiento de entradas es simplemente eliminar los apóstrofes de las entradas, lo cual es un enfoque increíblemente terrible.

Esto no protegerá contra el contrabando basado en Unicode e interferirá con propósitos legítimos para los apóstrofes en una base de datos, como los nombres de las personas. Imagine que intenta buscar el apellido de alguien en una base de datos, pero no puede porque hay un apóstrofe. Eso es tonto.

La solución correcta es la siguiente: validación de entrada (nulo > longitud > formato > lista blanca) ** > ** consultas parametrizadas > salida de saneamiento (para evitar XSS), que probablemente no están siguiendo. No hay ninguna razón legítima para excluir datos apropiados.

Esté de acuerdo con su análisis de que permitir símbolos permite mayor seguridad, pero generalmente no es mucho. Especialmente cuando se compara con usar contraseñas ligeramente más largas (suponiendo que la contraseña sea un símbolo elegido al azar). Usando cualquiera de los 95 caracteres ASCII imprimibles:

0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"#$%&\'()*+,-./:;<=>?@[\]^_'{|} ~

(algunos más si cuenta los caracteres como tabulador o salto de línea como imprimible) una contraseña de 8 caracteres tiene 95 ^ 8 ~ 6.6 x 10 ^ 15 posibilidades, mientras que con solo letras y números (con mayúsculas y minúsculas) una contraseña de 8 caracteres tiene 62 ^ 8 ~ 2.2 x 10 ^ 14, que es aproximadamente 30 veces más débil.

Sin embargo, una contraseña de 9 caracteres con solo números + minúsculas + mayúsculas es dos veces más fuerte que una contraseña de 8 caracteres que permite caracteres especiales. Por lo tanto, a menos que haya límites estrictos en la longitud de una contraseña (y en realidad nunca es necesario que haya al menos contraseñas de menos de unos pocos cientos de caracteres), es fácil pasar a contraseñas ligeramente más largas incluso con un conjunto de caracteres limitado. / p>

La mayor preocupación potencial de seguridad es si creen que permitir caracteres especiales en las contraseñas podría causar problemas en su aplicación o base de datos. Existe una razón legítima para excluir los caracteres ASCII no imprimibles (por ejemplo, los caracteres de control ASCII NUL ( \b ), retroceso ( ' ), etc.) que pueden causar problemas, pero las aplicaciones bien diseñadas deben poder manejarse caracteres especiales regulares como - o A3 sin ser vulnerables a los ataques de inyección. Una aplicación debe poder manejar estos tipos de caracteres tal como aparecen, por ejemplo, en nombres con comillas o guiones (por ejemplo, Conan O'Brien, Daniel Day-Lewis). Además, como las contraseñas no deben guardarse en la base de datos ni devolverse nunca al usuario y simplemente se las debe eliminar, lo que no debería importar caracteres ASCII imprimibles.

Por supuesto, hay algunos problemas de usabilidad con caracteres especiales que no son ASCII como Unicode, y para problemas de usabilidad puede ser una buena idea prohibir estos caracteres o normalizarlos de manera estándar. Las funciones de hash normalmente esperan una cadena de bytes, y las contraseñas con caracteres especiales más allá de ASCII se pueden codificar de diferentes maneras en el nivel de bytes (por ejemplo, UTF-8, UTF-7, UTF-16, ISO-8859-1). Además, además de las diferentes codificaciones (que podría mantener consistentes en el nivel de la aplicación), también debe preocuparse por que las letras de aspecto idéntico tengan valores diferentes en Unicode. Por ejemplo, el siguiente carácter Å es unicode 00C5 , pero este carácter de aspecto idéntico es Å < a href="http://www.fileformat.info/info/unicode/char/212b/index.htm"> unicode 212B mientras que este Å es en realidad dos caracteres: un ascii A con un carácter de combinación de unicode 030a agregando un círculo sobre la A.

EDIT : acabo de notar que mencionaste £ como uno de tus símbolos comunes. Desafortunadamente, ese no es un símbolo ASCII estándar. En ISO-Latin-1, es el byte C2 A3 . En UTF-8 son los dos bytes +AKM- . En UTF-7 son los caracteres ASCII 00 A3 . En UTF-16 es ' . Estas codificaciones diferentes significan que su función hash puede romperse en este carácter si no se maneja correctamente. Por supuesto, la aplicación debería poder manejar la codificación correctamente, pero podría fallar en algún subconjunto de dispositivos. Además, es posible que el carácter no esté disponible en teclados extranjeros.

También puede haber problemas de usabilidad con caracteres como " o ‘’“” que en algunas aplicaciones / plataformas pueden convertirse en comillas inteligentes %code% (aunque esto nunca debe hacerse en un contexto de contraseña).

Finalmente, hay una razón adicional para tener reglas de contraseña únicas: dificultar que los usuarios tengan una contraseña recordada que se reutiliza en todas partes, lo que es una práctica de seguridad horrible. Si la contraseña "normal" del usuario no cumple con las reglas únicas de un sitio, entonces cuando su contraseña normal se ve comprometida en otro sitio aleatorio (que dice que almacena la contraseña en texto sin formato), su cuenta no se compromete en el sitio con el único reglas.

Un poco largo recuperado pero ...

La madre de John recibe un iPad para Navidad, luego decidió iniciar sesión en su banco usándolo (en lugar de su computadora portátil), pero no puede averiguar cómo "escribir" el símbolo en el iPad. Así que le pide a alguien que le muestre cómo escribir su contraseña ...

Ahora piense en los problemas de soporte técnico con los clientes que tienen contraseñas que no saben cómo "escribir" en sus teléfonos o tabletas. La gran cantidad de llamadas de asistencia que solicitan que se restablezcan las contraseñas es un problema de seguridad así como un problema de costos.

Es posible que algunos de los símbolos no estén disponibles en todos los diseños de teclado con los que interactúa. Eso evitará que inicie sesión. Esto sería un problema para la disponibilidad, no para la seguridad.

Pero esto podría convertirse en un pequeño problema de seguridad si el símbolo en cuestión estuviera disponible en una distribución de teclado desconocida con la que está trabajando, pero no en una posición familiar. En ese caso, es posible que tenga que encontrar la clave correcta antes de escribirla en el campo de contraseña. Y (especialmente en ausencia de teclas clave coincidentes) posiblemente podría escribir símbolos en algún editor hasta que aparezca el símbolo que busca. Cuando se detenga allí, las personas que vean su editor (mientras escribe o más tarde porque olvidó cerrarlo) conocerán al menos uno de los símbolos contenidos en su contraseña.

Estoy de acuerdo con la respuesta de Eddie Studer : a pesar de que hay una implicación de seguridad inverosímil, es posible es que la persona que le contó esto no tenía ni idea de la verdadera razón detrás de esa política. Sin embargo, podría haber sido el problema de disponibilidad que mencioné por adelantado, ya que los usuarios no pueden iniciar sesión, por ejemplo. de cafés internet en países extranjeros. Solo para proporcionar una alternativa a las inquietudes de inyección expresadas por la mayoría de las otras respuestas, aunque esas son todavía una razón muy probable.

La mayoría de las personas no pueden escribir símbolos sin disminuir la velocidad y presionar varias teclas a la vez, por lo que hay una pequeña disminución en la seguridad si está tratando de escribir donde podría ser observado por un humano.

Tu argumento es:
1. una contraseña generada aleatoriamente con símbolos es más fuerte que una contraseña generada aleatoriamente de la misma longitud con solo letras y números
2. Por lo tanto, permitir símbolos en las contraseñas los hace más fuertes.

Esto es válido solo si las personas generan contraseñas al azar.
Sin embargo, comparemos una contraseña creada con el siguiente algoritmo:
1. crear una contraseña de longitud máxima - 1 con números y letras
2. pegar un símbolo al final

Suponiendo que el número de símbolos es menor que el número de letras y números, esto dará como resultado una contraseña más débil que una contraseña aleatoria de solo letras y números, además de proporcionar una falsa sensación de seguridad ('Lo puse en contraseña $ , no contraseña!). Se pueden hacer argumentos similares para generar contraseñas reemplazando letras con símbolos, etc.

Entonces, uno podría decidir que rechazaría los símbolos, con la esperanza de que la gente elija usar una contraseña aleatoria / más larga en lugar de pa$$word . Por supuesto, esto "lastima" a los usuarios que desean usar contraseñas aleatorias con letras + números + símbolos. Pero es de esperar que esos usuarios estén lo suficientemente informados para simplemente agregar algunos caracteres más, lo que dará como resultado una contraseña de fortaleza equivalente (suponiendo que no esté limitando la longitud).

En general, solo porque la inclusión de los símbolos en las contraseñas de algunas aumenta su fuerza, no se sigue que permitir que las personas utilicen símbolos incrementará la fuerza de la contraseña promedio.

Como alternativa a su propia seguridad, imagine que tiene que recordar una contraseña que contiene letras mayúsculas y minúsculas, dígitos y caracteres especiales, la mayoría de las personas que los utilizan escribirán esa contraseña en un papel, posiblemente junto con su nombre de usuario, que sería considerado alto riesgo de seguridad
Y si usa una contraseña más simple que pueda recordar, hay muchas menos posibilidades de que se filtre de usted. Por supuesto, de esta manera, bloquean su capacidad de usar contraseñas complicadas con el administrador de contraseñas, una solución más segura que una hoja de papel, pero aún así lo consideraría menos seguro que simplemente recordar su contraseña o frase de contraseña. Pero decir si tenían alguna razón razonable o simplemente su sistema o administración tiene fallas es imposible sin tener información privilegiada

Hipótesis de XML / Json:

Puede ser que la contraseña se envíe a un servicio web (con suerte a través de un canal seguro) y encontraron que los caracteres especiales dieron como resultado un XML o Json no válido. En lugar de escapar de las entidades, restringían todos los símbolos.

Un problema de seguridad es que si puedes usar los caracteres de escape " en XML y \" en Json y XML / Json está creado por concatenación de cadenas sin CDATA o su escape pueden terminar con una cita en el campo incluso si marcó la Cadena para comillas simples y dobles.

Por supuesto, la solución es evitar la concatenación de cadenas para crear consultas con parámetros externos.

P.S: La contraseña también puede ir a LDAP, lo que permite la posibilidad de inyecciones LDAP

Evito los símbolos en las contraseñas porque pueden ser difíciles de escribir, especialmente en diseños de teclado o dispositivos con los que no estoy familiarizado.

Además, lo que es más importante, a menudo no confío en todos los desarrolladores de software. Una vez utilicé contraseñas que contenían espacios. Algunos servicios más tarde cambiaron sus métodos de autenticación para que eliminaran los espacios en blanco de las contraseñas. Esto me hizo incapaz de iniciar sesión.

Mi temor es que cosas similares puedan suceder con otros símbolos también, especialmente si consideramos símbolos que no son ASCII. Por cierto, el hecho de que sus servicios de atención al cliente estén desalentando el uso de símbolos especiales es una clara indicación de que no se debe confiar en ellos y que pueden hacer cosas extrañas (ya sea ahora o en el futuro).

Después de todo, si piensa en los números, usar símbolos no es muy diferente de agregar algunos caracteres a su contraseña alfanumérica:

• 100 símbolos (todos los caracteres imprimibles en ASCII), longitud 8: 100 ⁸ combinaciones;
• 62 símbolos (letras y dígitos ASCII), longitud 9: 62 ⁹ combinaciones, mayor que 100 ⁸ .

Usar más símbolos ayuda, pero aumentar la longitud es mucho mejor (k ^x crece más rápido que x ^k ).

Como @dr jimbob dijo que está usando el carácter no imprimible £ en su contraseña !@£$%^&*() . Si elimina el carácter no imprimible £ de su contraseña, se aceptará cualquiera que sea el servicio. Esto se debe a que el cifrado de la contraseña se desarrolló en c o en Java en el nivel central para mantener el alto nivel de seguridad.

Es difícil hacer que las personas que no son de tecnología hagan que comprendan los caracteres que no se pueden imprimir. Así que el ejecutivo de atención al cliente le pidió que usara los caracteres alfanuméricos simples, no los especiales.

Pruebe su nueva contraseña con !@$%^&*() amablemente cambie la contraseña después de la prueba tal como se publicó en línea.

Simplemente hablando, los caracteres aceptados están entre ASCII 32 a 126

Esta secuencia en particular es solo mantener presionada SHIFT y escribir 1234567890. Por lo tanto, asumo que están desaprobando esta secuencia en particular porque es simple para un hacker y mucha gente lo hace. Por ejemplo, he visto a personas que usan QWERASDFZXCV para una contraseña que es insegura porque solo está presionando Shift y moviéndose hacia abajo en el lado izquierdo del teclado.

Pero los caracteres limitados son bastante comunes tanto para la contraseña como para el nombre de usuario.

En la informática segura, tiene algo que se llama superficie de ataque, vulnerabilidad y explotación. Separar es la confiabilidad.

Sí, más personaje es más aleatorio, pero también tienes una superficie de ataque más grande.

Puedes crear contraseñas suficientemente aleatorias con un conjunto de caracteres limitado. 36 ^ 8 = 2,821,109,907,456 es lo suficientemente aleatorio para la mayoría de las necesidades de seguridad. Si no es así, simplemente elevarlo a 10 o 12 caracteres. Solo puedes esperar que usen caracteres aleatorios. La vulnerabilidad es que hay contraseñas que puedes adivinar FistNameLastNaveYYMMDD donde YYMMDD es la fecha de nacimiento.

Algunos caracteres Unicode tienen el mismo aspecto. Puedes crear un diacrítico como un personaje separado. Estos caracteres no son los mismos: griego Ο, latín O y cirílico О.

Dependiendo del conjunto de caracteres (página de códigos) en su computadora, es posible que obtenga diferentes asignaciones. La idea es un conjunto seguro de caracteres deterministas en todos los conjuntos de caracteres.

Debe considerar la codificación HTML, la compresión a través de la red, la salazón, ... ¿Qué pasa con los caracteres de control?

Tienes que dibujar la línea en algún lugar y el hecho es que no necesitas un juego de caracteres grande para crear contraseñas suficientemente aleatorias.

Esto no se trata de que los programadores sean perezosos o deficientes. Se trata de entregar un código sólido y confiable. Con un conjunto de caracteres controlado puede probar mejor todas las posibilidades. Si algo extraño sucede en la transmisión, hay un conjunto de pruebas más pequeño para descubrir qué lo rompe.