Como dijiste, cuando usas una función de comparación de cadenas que no ha sido diseñada para resistir ataques de temporización, podría explotarse para adivinar la cadena con la que comparas.
La comparación de cadenas no cifradas y no cifradas de hecho filtrará la cadena original, ya sea una contraseña (ya sea almacenada en una base de datos o codificada), una ID de sesión, una dirección de correo electrónico o un token de autenticación multifactor, lo que significa que este ataque es no se limita al sentido común de "contraseñas".
Si las cadenas están encriptadas y el atacante conoce la función de encriptación (con las claves asociadas), entonces podría adivinar la cadena encriptada y luego descifrarla para obtener la cadena original.
Si las cadenas están con hash y el atacante conoce la función de hash (y la sal asociada, si hay alguna), entonces adivinar el hash será más difícil cada byte (debido a el efecto de avalancha ), lo que hace que sea muy difícil adivinar más que los primeros bytes del hash, pero eso puede ser suficiente para fuerza bruta si su cadena original no es suficiente entropía.
Esta recomendación es verdadera cuando se compara cualquier cadena suministrada por el usuario (ya sea que la tenga o no) con cualquier tipo de datos confidenciales (ver más arriba, personalmente considero que cualquier información relacionada con un usuario es confidencial). / p>