¿Qué normalización de Unicode(y otro procesamiento) es apropiada para las contraseñas al hash?
passwords unicode-normalization (1)
Si acepto Unicode completo para las contraseñas, ¿cómo debo normalizar la cadena antes de pasarla a la función hash?
Metas
Sin la normalización, si alguien configura su contraseña a "mañana" ( ma/u00F1ana ) en una computadora e intenta iniciar sesión con "mañana" ( ma/u006E/u0303ana ) en otra computadora, los hashes serán diferentes y el inicio de sesión fallará . Esto está bajo el control del usuario-agente o su sistema operativo.
- Me gustaría asegurarme de que esos hash a la misma cosa.
- No me preocupan los homoglifos como Α, А y A (griego, cirílico, latín).
Referencia
Formularios de normalización de Unicode: http://unicode.org/reports/tr15/#Norm_Forms
Consideraciones
- Cualquier procedimiento de normalización puede causar colisiones, por ejemplo,
"office" == "office". - La normalización puede cambiar el número de bytes en la cadena.
Mas preguntas
- ¿Qué sucede si el servidor recibe una secuencia de bytes que no es válida UTF-8 (u otro formato)? ¿Rechazar, ya que no se puede normalizar?
- ¿Qué sucede si el servidor recibe caracteres sin asignar en su versión de Unicode?
La normalización no está definida en el caso de entradas mal formadas, como el supuesto texto UTF-8 que contiene secuencias de bytes ilegales. Los bytes ilegales pueden interpretarse de manera diferente en diferentes entornos: rechazo, reemplazo u omisión.
Recomendación n. ° 1 : si es posible, rechace las entradas que no cumplan con la codificación esperada. (Sin embargo, esto puede estar fuera del control de la aplicación).
El Anexo 15 de Unicode garantiza la estabilidad de la normalización cuando la entrada solo contiene caracteres asignados:
11.1 Estabilidad de las formas normalizadas
Para todas las versiones, incluso antes de Unicode 4.1, se sigue la siguiente política:
Se garantiza que una cadena normalizada es estable; es decir, una vez normalizada, una cadena se normaliza de acuerdo con todas las versiones futuras de Unicode.
Más precisamente, si una cadena se ha normalizado de acuerdo con una versión particular de Unicode y solo contiene caracteres asignados en esa versión, se calificará como normalizada de acuerdo con cualquier versión futura de Unicode.
Recomendación n. ° 2 : cualquier forma de normalización que se use debe usar el Proceso de Normalización para Cadenas Estabilizadas , es decir, rechazar cualquier entrada de contraseña que contenga caracteres no asignados, ya que no se garantiza que su normalización sea estable en las actualizaciones del servidor.
Las formas de normalización de compatibilidad parecen manejar mejor el japonés, colapsando varias descomposiciones en la misma salida donde las formas canónicas no lo hacen.
La especificación advierte:
Los formularios de normalización KC y KD no deben aplicarse a ciegas a texto arbitrario. Debido a que borran muchas distinciones de formato, evitarán la conversión de ida y vuelta a muchos conjuntos de caracteres heredados y, a menos que se sustituyan por el formato, pueden eliminar las distinciones que son importantes para la semántica del texto.
Sin embargo, la semántica y los disparos no son motivo de preocupación aquí.
Recomendación n. ° 3 : aplique NFKC o NFKD antes de realizar el hash.