El protocolo SRP como se describe en RFC 2945 genera el verificador de contraseña:
x = SHA(<salt> | SHA(<username> | ":" | <raw password>))'
v = g^x % N
Tengo tres preguntas: ¿por qué usar SHA dos veces, por qué involucrar el nombre de usuario y por qué agregar un separador? ¿Éstos agregan alguna seguridad práctica sobre x = SHA(<salt> | <raw password>) ?
SHA-1 no es una función hash ideal (en realidad, tampoco lo son las funciones SHA-2). La invocación de doble hash oculta algunas de las deficiencias internas de SHA-1. Esto es similar a HMAC , que también utiliza una invocación de doble hash por casi las mismas razones. En más detalles, queremos que la función que asigna el nombre de usuario y la contraseña a x (función seleccionada por la sal entre una familia de funciones) se comporte como un oráculo aleatorio, y las propiedades de seguridad normales de Las funciones de hash (resistencia de colisión, resistencia de preimagen) no son suficientes para garantizar tal comportamiento.
El nombre de usuario está involucrado para facilitar las pruebas de seguridad: permite que el análisis de seguridad se concentre en un solo usuario, sin tener que dar cuenta de lo que sucede cuando un servidor determinado acepta varios usuarios, cada uno con su propia contraseña. El separador participa con el mismo objetivo: de lo contrario, "john" con la contraseña "ny67dtzo" y "johnny" con la contraseña "67dtzo" vivirían en el mismo mundo, desde el punto de vista de la seguridad.
El separador es una buena práctica de diseño criptográfico, siempre que se introduzcan varias cadenas en una función hash. Ayuda a evitar confusiones entre, por ejemplo, el nombre de usuario bob , la contraseña bydesign y el nombre de usuario bobby , la contraseña design .
El principio general de diseño es "Be cuidado al concatenar cadenas múltiples, antes de hacer hashing ". Puedes encontrar una explicación más detallada en ese enlace. Las violaciones de este principio de diseño han provocado fallas en el pasado, por lo que es una buena práctica seguir siempre el principio de diseño, incluso cuando no se puede pensar en un ataque obvio.
Lea otras preguntas en las etiquetas passwords authentication hash cryptography key-exchange