mutua instalar certificado autenticacion java web-services security rest authentication

java - instalar - Autenticación básica HTTP en lugar de certificación de cliente TLS



autenticacion mutua (3)

La respuesta a continuación es de this pregunta;

La respuesta otorgada en realidad no aborda la pregunta en absoluto. Solo menciona SSL en el contexto de la transferencia de datos y en realidad no cubre la autenticación.

Realmente está preguntando por la autenticación segura de los clientes de la API REST. A menos que use la autenticación de cliente TLS, SSL por sí solo NO es un mecanismo de autenticación viable para una API REST. SSL sin autenticación de cliente solo autentica el servidor, lo cual es irrelevante para la mayoría de las API REST.

Si no utiliza la autenticación de cliente TLS, deberá usar algo así como un esquema de autenticación basado en resumen (como el esquema personalizado de Amazon Web Service) o OAuth o incluso autenticación HTTP básica (pero solo a través de SSL).

Entonces, considerando que usaré HTTPS sin certificación de cliente, mi pregunta aquí es si el servidor de certificación SSL del cliente no sabe con quién está hablando. Lo que entiendo aquí es si uso un token de autenticación para acceder para autenticar al cliente contra el servidor. Entonces el servidor no sabe a quién está enviando el token, incluso si ese token está emparejado con una identificación de usuario en la base de datos de mi servidor.

Ante todo

1-¿es esto un problema real? Si utilizo especialmente Https? (Sin autenticación de cliente TLS)

2- y lo más importante, suponiendo que es un defecto de seguridad importante; ¿Cómo puede la autenticación básica Http ayudar aquí como se menciona el cartel? La autenticación básica Http solo envía una contraseña de usuario codificada en un encabezado. Entonces, cuando el cliente recibe un token ( a cambio después de que él envíe su contraseña de usuario), entonces, para el resto de sus solicitudes, usará este token en este encabezado en lugar de contraseña, y todo está bien, de repente?

Todavía el servidor no sabe de dónde viene la solicitud, tal vez el servidor tiene un token válido con un usuario coincidente en su base de datos, pero se desconoce quién realmente lo envía . (¡Aunque todavía veo esto muy difícil que la ficha sea robada sobre https y utilizada por otra persona!)

Cada vez que traigo este tema recibo respuestas ... "Bueno ... envían un token pero el servidor no sabe a quién enviar el token, no es muy seguro", así que entiendo esto, ya que el navegador mantiene una especie de certificación de autenticación y el servidor sabe dónde la solicitud viene del lugar correcto ENTONCES puedo estar seguro de que el usuario emparejado con ese token (marcado desde mi DB) es "realmente correcto"

O tal vez lo que estoy diciendo aquí no es correcto

[el] cartel dice que si no usamos el servidor de certificación SSL del cliente, realmente no sabemos con quién está hablando.

Eso no es lo que dije :) Esto es lo que dije:

A menos que use la autenticación de cliente TLS, SSL por sí solo NO es un mecanismo de autenticación viable para una API REST.

solo siendo la palabra clave aquí. También:

Si no usa la autenticación de cliente TLS, deberá usar algo así como un esquema de autenticación basado en resumen (como el esquema personalizado de Amazon Web Service) o OAuth o incluso autenticación HTTP básica (pero solo a través de SSL).

En otras palabras, la autenticación de cliente TLS es una forma de autenticar un cliente API REST. Debido a que la pregunta SO original se refería específicamente a SSL, mencioné que la autenticación de cliente TLS es la única forma de autenticación "integrada" si confía solo en TLS. Por lo tanto, si está utilizando TLS y no aprovecha la autenticación de cliente de TLS, debe usar otra forma de autenticación para autenticar a su cliente.

Hay muchas formas de autenticar clientes REST. La autenticación de cliente de TLS es solo una de ellas (la única "integrada" para TLS y generalmente muy segura). Sin embargo, TLS es un protocolo de nivel de red y la mayoría lo considera demasiado complicado para la configuración de muchos usuarios finales. Por lo tanto, la mayoría de las ofertas de API REST optan por un protocolo de nivel de aplicación más fácil de usar como HTTP porque es más fácil de usar para la mayoría (por ejemplo, simplemente configure un encabezado HTTP).

Por lo tanto, si va a la ruta del encabezado HTTP, debe usar un valor de encabezado para autenticar un cliente REST.

En la autenticación HTTP, tiene un encabezado, Authorization y su valor (el nombre del encabezado es bastante desafortunado porque generalmente se usa para la autenticación y no tan a menudo para el control de acceso, también conocido como autorización). El valor del encabezado Authorization es el que usa el servidor para realizar la autenticación, y está compuesto (generalmente) de tres tokens

  1. Un nombre de esquema de autenticación HTTP, seguido de
  2. espacio en blanco (casi siempre un carácter de espacio), seguido de
  3. El valor de texto específico del esquema.

Un esquema de autenticación HTTP común es el esquema Basic , que es muy ... bueno ... básico :). El valor de texto específico del esquema es simplemente el siguiente valor calculado:

String concatenated = username + ":" + raw_password; String schemeSpecificTextValue = base_64_encode(concatenated.toCharArray());

Por lo tanto, es posible que vea un encabezado correspondiente como este:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

El servidor sabe cómo analizar el valor. Dice "Oye, conozco el esquema Basic , así que voy a tomar el valor del texto final, lo decodificaré en base64, y luego tendré el nombre de usuario y la contraseña ingresada. Luego puedo ver si esos valores coinciden con lo que tengo almacenado ".

Y eso es esencialmente autenticación Basic . Debido a que este esquema en particular incluye la contraseña sin procesar base64 codificada, no se considera segura a menos que use una conexión TLS. TLS garantiza (principalmente) que las miradas indiscretas no pueden interceptar los encabezados (por ejemplo, a través de la inspección de paquetes) y ver cuál es la contraseña. Esta es la razón por la que nunca debe usar la autenticación HTTP básica a menos que esté sobre una conexión TLS. Siempre , incluso en entornos de intranet de la compañía.

Por supuesto, existen otros esquemas de Autenticación HTTP aún más seguros. Un ejemplo es cualquier esquema que usa autenticación basada en resumen.

Los esquemas de autenticación basados ​​en resumen son mejores porque su valor de texto del esquema no contiene la contraseña presentada. En cambio, se calcula un hash basado en contraseña de ciertos datos (a menudo otros campos y valores de encabezado) y el resultado se coloca en el valor del encabezado Authorization . El servidor calcula el mismo hash basado en contraseñas usando la contraseña que ha almacenado localmente. Si el valor calculado del servidor coincide con el valor del encabezado de la solicitud, el servidor puede considerar la solicitud autenticada.

Esta es la razón por la cual esta técnica es más segura: solo se transmite un hash, no la contraseña en sí misma. Eso significa que esta técnica se puede usar para autenticar solicitudes incluso a través de conexiones de texto claro (no TLS) (pero solo querría hacer esto si los datos de la solicitud en sí no son sensibles, por supuesto).

Algunos esquemas de autenticación basados ​​en resumen:

Stormpath y Amazon son más seguros para REST que OAuth 1.0a porque siempre autentican la carga útil de la entidad de solicitud. OAuth 1.0a solo hace esto para application/x-www-form-urlencoded content que no es relevante para API REST que usan application/xml o application/json payloads (que parece ser la mayoría de las API REST actualmente).

Curiosamente, OAuth2 no se basa en la digestión, sino que utiliza algo que considero menos seguro, llamado "token de portador", que en mi opinión es sintomático de los diversos problemas de OAuth 2.

Finalmente, y sí, este es un enchufe desvergonzado, pero si no quieres preocuparte por esto, simplemente utiliza Stormpath (muchos casos de uso son gratuitos). Automatizamos esto para que sus aplicaciones no tengan que hacerlo.

Cuando hablamos de "autenticar a un usuario", lo que realmente queremos decir es "verificar que el usuario sepa algo que nadie más debería saber". Ese "algo" podría ser una contraseña, un certificado, un token de seguridad de hardware o incluso el patrón retinal del usuario, pero en todos los casos es el acceso a esa información lo que realmente estamos verificando, no la identidad del usuario (lo que sea que realmente significa) como tal.

El punto es que, en principio, todos estos autenticadores podrían ser robados y utilizados para hacerse pasar por el usuario. Se podría registrar una contraseña, se podría copiar un certificado del disco en el que está almacenado, se podría robar un token de hardware (y posiblemente ingeniería inversa y clonarlo) e incluso, en principio, se podría escanear, registrar y falsificar el patrón retinal del usuario. lo mejor que podemos hacer es, en cada caso, tratar de hacer esto tan "muy difícil" como sea posible.

Tal vez estoy malinterpretando la pregunta.

La respuesta que me ha proporcionado me dice que si no usa algún tipo de autenticación, ya sean certificados de cliente, HTTP BASICAUTH u otra cosa, el servidor no sabe con quién se está comunicando.

(Tal vez está bien para su aplicación, tal vez no, solo usted puede responder eso).

Expresado en otros términos, si utiliza alguna forma de autenticación, el servidor sabe con quién se está comunicando; se está comunicando con la "persona" a quien pertenecen las credenciales autenticadas.

En este contexto, la autenticación es el proceso de establecer identidad a través de algunas credenciales.

La autenticación no garantiza que las credenciales no hayan sido robadas. SSL asegura (no iría tan lejos como para decir que "garantiza") que las credenciales están seguras en tránsito entre el cliente y el servidor.

Cuando usa GMail, está utilizando SSL, ¿cómo sabe Google que está hablando con usted ?