¿La autenticación sobre HTTPS ralentizará mi aplicación?

Estoy creando una aplicación web y un servicio web RESTful.

He estado leyendo varios artículos sobre la mejor manera de autenticar las solicitudes al servicio web.

La mejor opción para mí parece ser utilizar la autenticación básica HTTP. Casi todos los artículos que he leído dicen que la autenticación debe estar encriptada sobre SSL o equivalente.

No estoy totalmente seguro de lo que esto implica. ¿Significa esto que todo mi servicio web tendrá que estar en un servidor seguro? ¿Esto ralentizará las cosas?

En primer lugar, intente comprender cómo funciona la autenticación SSL (HTTPS) y HTTP.

Los métodos de autenticación HTTP habituales (resumen, básico y cualquier esquema de autenticación basado en formularios + cookies que puede implementar sobre HTTP) son inseguros por sí mismos, ya que envían información de autenticación más o menos en texto claro. Si los datos están en campos POST o encabezados, y si se aplica la codificación base64, no importa en absoluto a este respecto, la contraseña es claramente visible para cualquier persona con acceso al tráfico de red. Esto significa que la autenticación HTTP a través de un canal que no es de confianza no tiene valor: todo lo que necesita un atacante para leer su contraseña es detectar un poco la red.

SSL implementa un canal de comunicación seguro sobre un canal inherentemente inseguro. Esto funciona, más o menos, de la siguiente manera:

1. El servidor envía un certificado firmado
2. El cliente valida el certificado con una lista de claves de firma reconocidas; las firmas de certificados se pueden encadenar, de modo que cada nodo diga "si la firma que me firma es buena, entonces yo también lo soy", pero en última instancia, la cadena debe resolverse ante una de las pocas autoridades confiables preconfiguradas en el cliente.
3. El cliente usa la clave de cifrado pública del servidor para enviar un secreto compartido
4. El servidor descifra el secreto compartido usando la clave privada (porque solo el servidor legítimo tiene la clave privada, otros servidores no podrán descifrar el secreto compartido)
5. El cliente envía datos de solicitud reales, encriptados usando el secreto compartido
6. El servidor descifra los datos de la solicitud y luego envía una respuesta cifrada
7. El cliente descifra la respuesta y se la presenta al usuario.

Tenga en cuenta algunos puntos importantes aquí:

• La cadena de certificados permite a los clientes asegurarse de que el servidor con el que están hablando es el real, no que alguien intercepte sus solicitudes. Esta es la razón por la que debe comprar un certificado SSL real, y por qué los navegadores le lanzan advertencias espeluznantes cuando visita un sitio que usa un certificado no válido, caducado o incorrecto: todo el cifrado en el mundo no ayuda si está hablando con la persona equivocada.
• El cifrado público / privado utilizado para intercambiar el secreto asegura que la comunicación exitosa solo funcione entre este par particular de cliente y servidor: los paquetes de red rastreados se cifrarán y requerirán la clave privada del servidor para obtener los datos.
• El cifrado simétrico se utiliza para la mayor parte de la solicitud, ya que tiene una sobrecarga de rendimiento mucho menor que el cifrado de clave privada / pública. Sin embargo, la clave (secreto compartido) se intercambia mediante el cifrado de clave privada / pública, porque esa es la única forma de hacerlo de forma segura (excepto transportándola a través de un canal separado, como un servicio de mensajería).

Obviamente, hay algunos gastos generales involucrados, pero no es tan malo como parece: es principalmente en la escala donde "arrojar más hardware" es la respuesta adecuada, a menos que se esté preparando para cantidades de tráfico absolutamente masivas ( piensa en Google o Facebook). En circunstancias normales, es decir, el uso típico de aplicaciones web, la sobrecarga de SSL es insignificante y, en consecuencia, tan pronto como tenga datos confidenciales, es mejor ejecutar todo a través de SSL, incluidos los recursos. SSL también es la única forma viable de proteger el tráfico HTTP; otros métodos simplemente no están tan estandarizados y, por lo tanto, no son ampliamente compatibles, y absolutamente no desea implementar estas cosas usted mismo, porque honestamente, es demasiado fácil equivocarse.

TL; DR: Sí, SSL Autenticación + básico es una idea buena, sí, se necesita un servidor seguro (y un certificado válido ), sí, va a frenar las cosas un poco, pero no, esto no es algo que preocuparse por la derecha ahora.

HTTPS (SSL) no es autenticación de usuario para su información. Solo proporciona cifrado entre 2 puntos finales.

Pero sí, hay una pequeña cantidad de gastos indirectos (aunque no lo suficiente como para justificar un cambio en los planes / hardware). Mira aquí :

/programming/548029/how-much-overhead-does-ssl-impose

Con la autenticación básica HTTP, el nombre de usuario y la contraseña que proporciona el usuario se envían con cada solicitud al servidor. Esto significa que están en texto plano incluso en áreas de su sitio que no necesariamente necesitan ser seguras. Obviamente, querrá SSL aquí para mantener a sus usuarios seguros.

En teoría, podría usar la autenticación de cookies y solo poner SSL en la página de inicio de sesión (donde se envía el nombre de usuario y la contraseña). Si sus cookies son decentemente seguras y protegidas contra ataques de repetición, entonces un atacante no podría hacer nada con ellas, incluso si lograra obtener una.

La autenticación básica es establecer un nombre de usuario y contraseña en el encabezado de la solicitud http. Si no usa SSL o equivalente, entonces ese nombre de usuario y contraseña se envían en texto plano y es trivial para que cualquiera lo robe.

La mayoría de los servidores web admiten HTTPS fuera de la caja hoy en día y, aunque agrega una sobrecarga a cada llamada, esa sobrecarga es mínima.

Puede asegurar algunos puntos finales y no otros (es decir, tener un punto final autenticado que produzca un token que pueda usarse para otras llamadas). Sin embargo, recomendaría SSL para todo el servicio, ya que es mucho más seguro. (si nada más, detiene la intercepción de datos confidenciales)

Jeff Atwood escribió una breve publicación en el blog no hace mucho tiempo sobre si el cifrado completo es el camino a seguir. Describe algunos ejemplos del mundo real y también tiene algunas líneas sobre consideraciones de rendimiento.

Además, hace referencia a este artículo sobre un estudio de caso de Gmail, citando lo siguiente:

En enero de este año (2010), Gmail cambió a usar HTTPS para todo de forma predeterminada. Anteriormente se había introducido como una opción, pero ahora todos nuestros usuarios usan HTTPS para asegurar su correo electrónico entre sus navegadores y Google, todo el tiempo. Para hacer esto, no tuvimos que implementar máquinas adicionales ni hardware especial. En nuestras máquinas frontales de producción, SSL / TLS representa menos del 1% de la carga de la CPU, menos de 10 KB de memoria por conexión y menos del 2% de la sobrecarga de la red. Muchas personas creen que SSL requiere mucho tiempo de CPU y esperamos que los números anteriores (públicos por primera vez) ayuden a disipar eso.

También menciona algunas mejoras recientes en el almacenamiento en caché de páginas del lado del cliente a través de HTTPS por parte del navegador .

A pesar de esto, señala, hay otras sanciones, la mayoría de las cuales no son el rendimiento sino los costos de implementación:

• Mantener la calidad del software al tiempo que agrega complejidad adicional para los equipos ya ocupados,
• El almacenamiento en caché de proxy es mucho más difícil de configurar correctamente y también necesita cambios de código,
• Es difícil obtener la seguridad adecuada para una combinación de contenido de diferentes fuentes,
• Los dispositivos móviles de gama baja pueden tener problemas con el cifrado.

La autenticación básica HTTP sin su propio manejo de sesión probablemente lo dejará abierto a ataques de falsificación de solicitudes en sitios cruzados. Probablemente pueda usarlo si se combina con el manejo de su propia sesión, pero puede tener problemas para proporcionar una función limpia de "cerrar sesión".

No importa lo que use para la autenticación, deberá usar HTTPS para cifrar la conexión (a menos que solo se acceda a la aplicación web en una red segura y controlada). Puede ralentizar un poco las cosas (los establecimientos de conexión son caros, pero los navegadores tienden a mantener las conexiones por un tiempo), pero si desea una aplicación segura, no podrá evitarla de todos modos, por lo que realmente no necesita preocuparse por eso.

Nota: La "autenticación HTTPS" (que mencionó en el título) es engañosa: podría referirse a la autenticación de certificado de cliente SSL, que tiene poco que ver con el texto de su pregunta y tiene su propio conjunto de beneficios y problemas. Probablemente no quieras tocar eso.

¿Cómo vas a lograr la autenticación básica?
Si es un nombre de usuario / contraseña codificado y está utilizando la funcionalidad integrada de su servidor web para hacerlo, es probable que tenga un impacto casi nulo. Si está haciendo cosas locas en una base de datos o algo similar, entonces sí podría haber un impacto.

Como otros han señalado aquí, SSL y el envío de encabezados adicionales técnicamente harán las cosas más lentas, pero no serán significativas de ninguna manera.