¿Qué es la autenticación implícita?

101

¿En qué se diferencia la autenticación implícita de la autenticación básica además del envío de credenciales como texto sin formato?

digest-authentication

— SoftwareGeek
fuente

Gran explicación de @Gumbo aquí mismo: stackoverflow.com/a/5288679/591487

— inorganik

Algo que NUNCA deberías usar. No protege la contraseña en tránsito y requiere que el servidor almacene las contraseñas sin formato.

— CodesInChaos

Digest proporciona una mejor seguridad en tránsito que la autenticación básica para el tráfico no cifrado , pero es débil. Es MUCHO más seguro utilizar la autenticación básica en combinación con SSL / TLS, porque de esa manera también puede mantener cifradas las contraseñas del servidor.

— rustyx

Respuestas:

179

La principal diferencia es que no requiere enviar el nombre de usuario y la contraseña a través del cable en texto plano. También es inmune a los ataques de repetición, ya que utiliza un número único del servidor.

El servidor le da al cliente un número de uso único (un nonce) que combina con el nombre de usuario, reino, contraseña y la solicitud de URI. El cliente ejecuta todos esos campos a través de un método hash MD5 para producir una clave hash.

Envía esta clave hash al servidor junto con el nombre de usuario y el reino para intentar autenticarse.

En el lado del servidor, se usa el mismo método para generar una clave hash, solo que en lugar de usar la contraseña ingresada en el navegador, el servidor busca la contraseña esperada para el usuario en su base de datos de usuario. Busca la contraseña almacenada para este nombre de usuario, se ejecuta mediante el mismo algoritmo y la compara con lo que envió el cliente. Si coinciden, se concede acceso; de lo contrario, puede devolver un 401 No autorizado (sin inicio de sesión o inicio de sesión fallido) o un 403 Prohibido (acceso denegado).

La autenticación implícita está estandarizada en RFC2617 . Hay una buena descripción general en Wikipedia :

Puedes pensar en ello así:

El cliente hace una solicitud
El cliente recibe un nonce del servidor y una solicitud de autenticación 401
El cliente devuelve la siguiente matriz de respuesta (nombre de usuario, reino, generate_md5_key (nonce, username, realm, URI, password_given_by_user_to_browser)) (sí, eso es muy simplificado)
El servidor toma el nombre de usuario y el dominio (además, conoce el URI que solicita el cliente) y busca la contraseña para ese nombre de usuario. Luego va y hace su propia versión de generate_md5_key (nonce, username, realm, URI, password_I_have_for_this_user_in_my_db)
Compara la salida de generate_md5 () que obtuvo con la que envió el cliente, si coinciden con la contraseña que envió el cliente. Si no coinciden, la contraseña enviada es incorrecta.

— Ian C.
fuente

Buena explicación. ¿Son el nombre de usuario y la contraseña para un usuario de Windows? ¿De dónde se generan?

— SoftwareGeek

Son lo que el usuario escriba en el navegador. La contraseña debe coincidir con lo que el servidor haya almacenado para la contraseña de ese usuario. Lo más probable es que sea algo específico de esa aplicación web y no su contraseña de Windows. Depende en gran medida de la forma en que se construya la aplicación web.

— Ian C.

Esta respuesta tiene 6 años, pero supongo que todos los sistemas conscientes de la seguridad almacenan contraseñas en un formato de hash con sal. No existe, y no debería existir, ningún método para obtener la contraseña original de la base de datos, lo que hace imposible la autorización de resumen.

— Ramon de Klein

Si compendio de hash de nombre de usuario y la contraseña se almacena en dB en lugar de las contraseñas de fricción, entonces sigue siendo posible utilizar digerir auth @RamondeKlein

— karakays

@BlueBockser Creo que karakays significaba que en lugar de usar una contraseña simple, un hash resultante de combinar el nombre de usuario y su contraseña debe almacenarse en el servidor al registrarse y calcularse en el lado del cliente antes de autenticarse. También se puede hacer con solo un hash de la contraseña.

— logo_writer

Se envía un hash de las credenciales por cable.

HA1 = MD5(username:realm:password)

Wikipedia tiene un excelente artículo sobre este tema.

— Philip Fourie
fuente

de cliente a servidor? ¿Podría proporcionar los pasos para la interacción? El artículo de Wikipedia es bueno pero necesito una mejor explicación o ejemplo.

— SoftwareGeek

Sí, el cliente genera el valor hash y lo envía al servidor. El artículo de Wikipedia describe el protocolo en detalle, le sugiero que lo consulte para obtener más información.

— Philip Fourie

La única forma de obtener el hash HA1 de las credenciales es conocer la contraseña. El servidor conoce HA1 pero no la contraseña que la generó. Si un atacante conocía HA1, podría ingresar al sistema. Entonces no se envía por el cable. Se realiza un hash adicional basado en nonce, etc. antes de hacer esto, y esto debe coincidir con un cálculo similar realizado en el servidor. Por lo tanto, mientras el servidor mantenga la privacidad de HA1, el sistema es seguro.

— Chris Oakley
fuente

Esta es la explicación para la autenticación implícita, donde la contraseña no se envía en texto sin formato (que es el caso de la autenticación básica)

— Erik Oppedijk