Supongamos que tengo una aplicación de escritorio que hace hashing de contraseña para la autenticación de inicio de sesión.
¿La contraseña normalmente está oculta antes de viajar a los cables o primero viaja a los cables en texto sin formato y después se hash?
Depende de la implementación específica de la aplicación de escritorio. Si los desarrolladores estuvieran razonablemente preocupados por la seguridad, no enviarían la contraseña a través de la red en texto claro. Pero es completamente posible que los desarrolladores de la aplicación hayan enviado la contraseña en texto simple.
Si desea averiguar qué método utiliza su aplicación en particular, generalmente necesitará usar algo como Wireshark para inspeccionar el Tráfico de red durante el proceso de inicio de sesión. Eso le mostrará si alguna aplicación en particular está enviando la contraseña en texto sin cifrar a través de la red.
Si su aplicación de escritorio tiene algo que ver con "los cables", supongo que prevé la siguiente configuración: la aplicación es la que solicita la contraseña del usuario, pero la verificación real de la contraseña se realiza en otro lugar, en una servidor de autenticación remota . Esto sería típico de una red basada en Windows con Active Directory , o redes basadas en Unix con Yellow Pages o un LDAP server para las contraseñas.
Nunca desea enviar una contraseña, con hash o no, "en texto sin formato a través de los cables". De hecho, en un simple proceso de inicio de sesión, la aplicación envía algo al servidor, y ese algo es suficiente para que se le otorgue acceso. Un intruso podría simplemente grabar este algo y reproducirlo más tarde. No importa si este algo es una secuencia de letras que tiene sentido para un ser humano, o una secuencia de otros bytes que pueden o no ser un valor de hash. Siempre que lo que el cliente envíe sea suficiente para desbloquear las cosas, entonces el debe de envío debe estar protegido de las miradas indiscretas de los intrusos, y esto requiere SSL / TLS , que garantiza la confidencialidad de los datos.
Otro punto importante es que los atacantes pueden estar activos . Un atacante activo es aquel que ha secuestrado un enrutador entre dos máquinas y puede alterar los datos en tránsito a voluntad. En el escenario de una aplicación de escritorio que habla con un servidor de autenticación, el atacante activo podría cambiar la respuesta del servidor de autenticación de un "No" grave a un cálido "Sí", simulando así un inicio de sesión exitoso aunque la contraseña sea incorrecta. De nuevo, se necesita protección, esta vez para mantener integridad ; SSL / TLS también hace eso.
Por lo tanto, hay dos buenas razones para usar SSL o un protocolo con características similares: el cliente tiene alguna garantía de que habla con el servidor correcto, los datos están cifrados y hay un MAC que protege contra alteraciones. SI se utiliza un protocolo de este tipo, ENTONCES, la contraseña se puede enviar "tal como está" en el túnel (protegido) y no hay ningún punto en el hashing o en el cifrado.
Tenga en cuenta que hay algunos protocolos de autenticación (por ejemplo, CRAM-MD5 ) que utilizan un tratamiento más complejo, incluido el hashing en el lado del cliente; Lo hacen porque asumen que no hay un túnel tipo SSL. Al utilizar un desafío del servidor, junto con la contraseña del cliente, protegen contra ataques de repetición . Sin embargo, todavía son débiles contra los atacantes activos; también, permiten que los espías aprendan valores hash calculados a través de contraseñas, que es suficiente para ejecutar ataques de diccionario sin conexión (el "espía" intenta " contraseñas potenciales en sus propias máquinas, limitadas solo por el número de PC que puede reunir). Por estas razones, un túnel protegido como SSL se considera una solución mucho mejor. Como subproducto, el túnel de tipo SSL hace que el hashing del lado del cliente sea irrelevante. Esto hace que la tarea de la aplicación cliente sea mucho más fácil. En realidad, hace que la tarea sea mucho más fácil que la "aplicación" del cliente puede ser un simple formulario HTML en la página web.
La práctica más común es que el cliente envíe al servidor el texto sin formato de la contraseña (preferiblemente mientras usa SSL) y luego el servidor lo vuelve a colocar para comparar con la base de datos. El punto de hash es prevenir la exposición de las contraseñas accediendo a la base de datos de autenticación.