¿Es una buena idea usar todo el rango Unicode para generar una contraseña aleatoria en lugar de rangos limitados? [duplicar]

Esta es una buena idea desde una perspectiva de seguridad. Una contraseña que contenga caracteres Unicode sería más difícil que una contraseña que contenga caracteres ASCII de la misma longitud. Esto se mantiene incluso si se compara la longitud de bytes en lugar de la longitud de caracteres, porque Unicode utiliza el bit más significativo, mientras que ASCII no.

Sin embargo, creo que no sería práctico ya que los errores de Unicode son tan comunes. Creo que si usa contraseñas de Unicode en cualquier lugar, encontrará más de un par de sitios en los que tendría problemas para iniciar sesión, porque los desarrolladores no implementaron correctamente el soporte de Unicode para las contraseñas.

Esto se parece mucho a la seguridad de Fencepost. Imagine que está ejecutando una instalación que tiene cercas de eslabones de cadena alrededor de 500 pies de altura. ¿Cuánto mejoraría la seguridad al hacer que la cerca sea de 3,000 pies de altura? Ninguna, porque cualquiera que intente entrar no va a subir los 500 pies; cavarán debajo, cortarán un agujero, etc.

Del mismo modo, tiene una contraseña que es, digamos, 20 caracteres alfanuméricos aleatorios. Eso es 62 ^ 20 posibilidades. Estás considerando cambiarlo a 20 caracteres Unicode aleatorios. Lo que aumenta la posibilidad de que el espacio sea mucho mayor, excepto que una contraseña aleatoria de 20 caracteres que impone el uso de fuerza bruta no es la forma en que las cosas se pondrán en peligro.     

Ignorar el argumento de Seguridad por Obscuridad es una cuestión básica de entropía. Una contraseña Unicode de 8 caracteres es más segura que una contraseña ASCII de 8 caracteres, pero menos segura que una contraseña ASCII de 64 caracteres.

En general estoy de acuerdo con Sjoerd, ya que es probable que causen más inconvenientes que beneficios. Además de esto, si alguna vez necesitas ingresar manualmente una contraseña aleatoria, es probable que Unicode haga que tu vida sea miserable.

Sin embargo, para el caso perimetral en el que necesita usar un servicio que admite activamente Unicode al tiempo que se aplica un límite de longitud máxima de contraseña (una vez más, ignorarlo significa otras fallas de seguridad), hay un argumento para ello.

El único motivo válido que se me ocurre para usar caracteres Unicode en contraseñas es si el número de caracteres (no los bytes) en una contraseña para un sitio en particular es limitado (como este banco tonto que anteriormente tenía un máximo de 10 caracteres), por lo que sería fácil de adivinar en un día o dos. En este caso, puede usar Unicode (si los propietarios del sitio le permiten) obtener más entropía en su contraseña mientras tanto, y le pide a los propietarios del sitio que cumplan con NIST 800-63-3 y elimine las restricciones de longitud (y el hash correctamente para que el almacenamiento de contraseñas no sea una preocupación).

También quería corregir una idea errónea aquí:

  

Unicode utiliza el bit más significativo, mientras que ASCII no.

Si bien es cierto para el ASCII normal, el ASCII extendido que algunos administradores de contraseñas (por ejemplo, KeePass) pueden usar en la generación de contraseñas usa cada bit de cada byte, por lo que tiene una densidad entrópica más alta que incluso Unicode, que todavía tiene cierta estructura para indique cuántos de los siguientes bytes forman parte del mismo carácter (tenga en cuenta que hay algo así como secuencia de bytes no válida en Unicode ).

Dado que un sitio que lo limita a contraseñas cortas probablemente ni siquiera tiene sus contraseñas correctamente (lo que hace que las contraseñas de Unicode fallen o se almacenen con la codificación incorrecta), casi nunca debería perder el tiempo para molestarse con las contraseñas de Unicode, porque mientras estás tan distraído con tus personajes divertidos (y el hecho de que tienes que restablecer tu contraseña porque estaba almacenada de forma extraña), un atacante podría estar adivinando tu (in) -seguras de seguridad o usando criptografía de chocolate para Acceda a su cuenta.

Este enfoque podría reducir su seguridad general en ciertos casos, no mejorarla.

La seguridad de la información consta de tres atributos: Confidencialidad, integridad y disponibilidad (la tríada de la CIA ). Al centrarse exclusivamente en uno, puede pasar por alto fácilmente la importancia de los demás.

La confidencialidad de las contraseñas se logra a través de los principios de la entropía: ¿qué tan 'impensable' es su contraseña? Esto se mide comúnmente por el tamaño del espacio de adivinación de fuerza bruta, expresado en términos de potencias de 2 o bits. Un atacante de fuerza bruta solo tiene tanta capacidad para adivinar; Al seleccionar una contraseña más larga para aumentar esta entropía, puede exceder cualquier capacidad conocida o prevista para adivinar. Obtener la entropía de más de 80 bits (o elegir su valor) pondrá la contraseña fuera del alcance de los actores del estado de la nación. Independientemente de la descripción demasiado simplificada de arriba, el punto es que ir más allá de lo que sea "fuera de alcance" no aumenta significativamente su seguridad. Y no es relevante para la seguridad si logra la entropía deseada utilizando 10 caracteres Unicode o 17 caracteres ASCII.

Disponibilidad significa "¿puedo acceder a mis datos cuando los necesito?" Si usa juegos de caracteres Unicode completos, corre el riesgo de verse afectado por varios sitios que no son compatibles con Unicode, o los navegadores o sistemas operativos que implementan Unicode de manera incorrecta, o los sitios que de manera invisible convierten Unicode a ASCII bajo las carátulas. La confusión resultante aumenta el riesgo de restringir su acceso futuro a los datos. Esto representa una disminución potencial en la disponibilidad futura.

En general, la probabilidad de que un atacante cometa una contraseña de 80 bits no es tan alta como la probabilidad de encontrar un sitio mal codificado que no maneje Unicode correctamente. Por lo tanto, su seguridad general podría disminuir en lugar de aumentar.

Por supuesto, muchos sitios tienen una longitud de contraseña y otras restricciones que también limitan drásticamente la entropía de sus contraseñas. En esos casos, el uso del conjunto completo de Unicode puede aumentar la entropía de sus contraseñas, asumiendo que no tienen otros defectos ocultos. Entonces, en esos sitios, puedes estar mejorando tu seguridad; pero es prácticamente imposible saber desde el exterior si un sitio está administrando correctamente los datos de su contraseña.

Puede que esta no sea una respuesta directa, pero si la contraseña solo se mantiene digitalmente, debe preguntarse por qué está generando una contraseña , en lugar de una matriz de bytes. Una vez que se ve todo como simples bytes, la pregunta ya no se aplica.

También, longitud > La complejidad en todo lo relacionado con las contraseñas.

Hay un RFC en su problema: Preparación, cumplimiento y comparación de cadenas internacionalizadas que representan nombres de usuario y contraseñas cuyo resumen es:

  

Este documento describe métodos actualizados para manejar cadenas Unicode   representando nombres de usuario y contraseñas. El enfoque anterior fue   conocido como SASLprep (RFC 4013) y se basó en Stringprep (RFC 3454).   Los métodos especificados en este documento proporcionan una   enfoque al manejo de nombres de usuario internacionalizados y   contraseñas.

Si lees francés, también puedes encontrar una buena explicación aquí: enlace .

La Sección 8 de la RFC se ocupa específicamente de la seguridad de las contraseñas usando "cualquier" carácter Unicode, con las siguientes secciones:

• 8.1. Contraseña / Frase de contraseña
• 8.2. Comparación de contraseña / frase de contraseña
• 8.3. Comparación de identificadores
• 8.4. Reutilización de PRECIS
• 8.5. Reutilización de Unicode

Agregando a las otras respuestas correctas, solo quiero señalar qué puede ir mal en el proceso utilizando el conjunto completo de Unicode para las contraseñas.

Suponiendo que usas aleatoriamente una cadena UTF-8 más o menos válida,

• hay caracteres interpretados como saltos de línea en el medio del Plano Multilingüe Básico como U + 2029 Separador de párrafo . Es posible que no pueda ingresarlas en un campo <input> .
• hay dos caracteres de espacio en blanco que pueden o no eliminarse con el método trim() de un idioma
• si usa caracteres sustitutos (U + D800-U + DFFF), no caracteres como U + FDD0 , caracteres de uso privado o caracteres no asignados (aunque secuencias UTF-8 válidas) el comportamiento de cualquier el conjunto de herramientas dado es básicamente indefinido (eliminar, reemplazar, rechazar, no hacer nada o cualquier combinación de estos)
• si agrega diacríticos, cualquier herramienta en curso podría cambiar eso a la representación NFC o NKD , cambiando los bytes en la contraseña.
• y eso es solo desde la parte superior de mi cabeza. Estoy seguro de que olvidé muchos otros problemas posibles, si las contraseñas se eligen de todo el rango Unicode.

Entonces, de manera similar a lo que sugirió @JohnDeters, podría ser una mala idea porque la ventaja de un espacio fuente más grande se ve contrarrestada por las partes móviles del procesamiento de texto en el camino.

Lo que cuenta para la seguridad es la entropía de la contraseña: cuántos bits de información real hay en la contraseña.

El otro lado del problema es lo difícil que es recordar la contraseña y escribirla. Imagina que intentas escribir tu contraseña en un iPhone y te das cuenta de que no puedes (no he comprobado lo difícil que es escribir caracteres arbitrarios de Unicode). O te das cuenta de que es muy, muy difícil escribirlo al 100% correctamente. O simplemente te lleva años: puede que tenga una contraseña con la misma entropía y más caracteres, pero el doble de rápido para escribir. Y necesitas cuatro intentos para hacerlo bien, mientras que el mío es correcto la primera vez.

Otros han comentado ampliamente el riesgo de que los servicios para los que usa esas contraseñas no implementen Unicode correctamente. Agregaré que los servicios que today do tomorrow dejen de hacerlo, pero de lo contrario me saltaré ese tema.

Un elemento que creo que debe considerarse aquí es preguntar: ¿cuánto tiempo debe tener una contraseña para alcanzar un cierto nivel de seguridad? Supongamos que queremos que nuestras contraseñas sean tan sólidas como una clave criptográfica de 128 bits (lo que probablemente sea una exageración para la mayoría de las contraseñas de sitios web; recomiendo 80 bits). Si se adhiere a contraseñas ASCII aleatorias, entonces una contraseña de 19 caracteres extraída de los 95 caracteres ASCII imprimibles alcanza ese nivel. (La matemática: un conjunto de aproximadamente 100 elementos es aproximadamente 6.6 bits / elemento (ya que log2 (10) ≈ 3.3, y log2 (100) es el doble), y 128 ÷ 6.6 ≈ 19.4. Entonces, 19 caracteres ASCII en realidad son aproximadamente 126 bits, no 128, pero meh.)

En la actualidad, Unicode tiene cerca de 130,000 puntos de código definidos, un número que aproximaremos como 2 ^ 17. Esto significa que para alcanzar el nivel de 128 bits necesita 7 puntos de código Unicode (128 ÷ 17 ≈ 7.5, por lo que 7 puntos de código son solo unos 119 bits, pero, nuevamente, meh.)

Para el nivel de seguridad de 80 bits, que creo que es más sensible para la mayoría de los sitios web, es de 12 caracteres ASCII frente a 5 puntos de código Unicode.

¿Estás dispuesto a dar un golpe masivo de usabilidad y arriesgar errores de sitios web para que puedas tener contraseñas de 5 o 7 caracteres en lugar de 12 o 19 caracteres? Simplemente no creo que valga la pena.

Bueno, Unicode es 'solo' una lista de algo con más de 130000 caracteres. UTF-8 es la codificación más común que toma ese número grande y lo 'convierte' en un número base-256 (o más precisamente, las reglas tienen más sentido en octetos binarios) de acuerdo con un conjunto de reglas. Por lo tanto, si desea utilizar una codificación utf-8, estará sujeto a muchas reglas que reducen de forma efectiva la aleatoriedad que pueda desear. Y no sé cómo podría usar toda la interpretación de Unicode.

Si no está preocupado por los caracteres imprimibles, puede considerar el ASCII completo (o más preferiblemente una extensión de 8 bits), pero en ese punto, ¿por qué molestarse con el estándar de interpretación de caracteres? ¿No podrías simplemente usar una estructura binaria aleatoria simple y sin forma entonces?

Incluso si solo usas almacenamiento digital, odiaría ser el usuario que necesitaba escribir algo y no reconocía la diferencia entre （y (. (Sugerencia: son dobles y simples espaciado)

Usando este ejemplo sensible al ancho, como se indica en otras respuestas, se espera que el soporte de estas funcione. Dependiendo de la intercalación de SQL establecida aquí, ¡una contraseña incorrecta sería correcta!

No. Desea aumentar la base de una función exponencial y arriesgarse a romper muchas cosas (es decir, dispositivos que no pueden escribir sus caracteres especiales, etc.). Calcule la entropía de su contraseña de Unicode y alargue su contraseña de ASCII hasta que tenga más entropía.

a-z solo es 26 ^ (longitud). digamos que obtienes 256^(length) y posiblemente 2 bytes por carácter con unicode. Entonces puedes encontrar el punto de equilibrio 26^(ascii_length) > 256^(2*unicodelength) en algún lugar. Elija esta longitud como ascii_length y aún puede escribir su contraseña y tener la misma seguridad.

Si el sitio no admite contraseñas largas (vergüenza de ellas), sospecho que tampoco pueden garantizar un buen soporte de Unicode. Tal vez usted estará bloqueado la próxima vez que actualicen alguna biblioteca interna. Entonces, ¿por qué arriesgar un problema allí? Y un problema, que es difícil de explicar al soporte de usuarios, que apenas sabe qué significa Unicode.

No es una buena idea generar contraseñas aleatorias de Unicode, ya que la contraseña generada puede ser ilegible para el usuario. Pero el texto de la pregunta habla sobre el uso de contraseñas de Unicode, y esta es una buena idea y se recomienda en la sección NIST 800-63-3 5.1.1.2 Verificadores de Secretos Memorizados que dice:

  

Los verificadores DEBERÁN requerir que los secretos memorizados elegidos por el suscriptor estén en   Mínimo 8 caracteres de longitud. Los verificadores DEBERÍAN permitir   Secretos memorizados elegidos por el suscriptor de al menos 64 caracteres de longitud.   Todos los caracteres ASCII [RFC 20] de impresión así como el carácter de espacio   DEBE ser aceptable en los secretos memorizados. Unicode [ISO / ISC 10646]   los caracteres DEBERÍAN ser aceptados también.

     

A los fines de los requisitos de longitud anteriores, cada punto de código Unicode   SE DEBE contabilizar como un solo carácter.

Continúa:

  

Si los caracteres Unicode se aceptan en secretos memorizados, el verificador   DEBE aplicar el proceso de normalización para cadenas estabilizadas usando   ya sea la normalización NFKC o NFKD definida en la Sección 12.1 de   Estándar Unicode Anexo 15.

Para resumir: el uso de Unicode aumenta la entropía y facilita la vida a los usuarios que no dominan el inglés.