Te recomendamos que revises esta resolución en un entorno controlado antes de pasarlo a producción, un saludo.
Solución:
El uso de HTTP con SSL hará que su vida sea mucho más fácil y puede estar tranquilo. Personas muy inteligentes (¡al menos más inteligentes que yo!) han analizado este método de comunicación confidencial durante años.
La autenticación segura es un tema amplio. En pocas palabras, como mencionó @jeremy-powell, siempre prefiera enviar credenciales a través de HTTPS en lugar de HTTP. Le quitará muchos dolores de cabeza relacionados con la seguridad.
Los certificados TSL/SSL son bastante baratos en estos días. De hecho, si no quiere gastar dinero en absoluto, hay un letencrypt.org – Autoridad de certificación automatizada.
Puede ir un paso más allá y utilizar caddyserver.com que llama a letsencrypt en segundo plano.
Ahora, una vez que eliminamos HTTPS…
No debe enviar el nombre de usuario y la contraseña a través de la carga útil POST o los parámetros GET. Use un encabezado de Autorización (Básico autenticación de acceso esquema) en su lugar, que se construye de la siguiente manera:
- El nombre de usuario y la contraseña se combinan en un string separados por dos puntos, por ejemplo: nombre de usuario:contraseña
- La resultante string se codifica con la variante RFC2045-MIME de Base64, excepto que no se limita a 76 caracteres/línea.
- El método de autorización y un espacio, es decir, “Básico”, se coloca antes del código string.
fuente: Wikipedia: encabezado de autorización
Puede parecer un poco complicado, pero no lo es. Existen muchas bibliotecas buenas que le proporcionarán esta funcionalidad lista para usar.
Hay algunas buenas razones por las que debería usar un encabezado de autorización
- es un estándar
- Es simple (después de aprender a usarlos)
- Le permitirá iniciar sesión en el nivel de URL, así:
https://user:[email protected]/login(Chrome, por ejemplo, lo convertirá automáticamente enAuthorizationencabezamiento)
IMPORTANTE:
Como señaló @zaph en su comentario a continuación, enviar información confidencial como una consulta GET no es una buena idea, ya que lo más probable es que termine en los registros del servidor.
Puede utilizar un esquema de respuesta de desafío. Digamos que tanto el cliente como el servidor conocen una S secreta. Luego, el servidor puede estar seguro de que el cliente conoce la contraseña (sin revelarla) al:
- El servidor envía un número aleatorio, R, al cliente.
- El cliente envía H(R,S) de regreso al servidor (donde H es una función hash criptográfica, como SHA-256)
- El servidor calcula H(R,S) y lo compara con la respuesta del cliente. Si coinciden, el servidor sabe que el cliente conoce la contraseña.
Editar:
Aquí hay un problema con la frescura de R y el hecho de que HTTP no tiene estado. Esto se puede manejar haciendo que el servidor cree un secreto, llámelo Q, que solo el servidor lo sabe. Entonces el protocolo es así:
- El servidor genera un número aleatorio R. Luego envía al cliente H(R,Q) (que el cliente no puede falsificar).
- El cliente envía R, H(R,Q) y calcula H(R,S) y lo envía todo de regreso al servidor (donde H es una función hash criptográfica, como SHA-256)
- El servidor calcula H(R,S) y lo compara con la respuesta del cliente. Luego toma R y calcula (nuevamente) H(R,Q). Si la versión del cliente de H(R,Q) y H(R,S) coincide con el nuevo cálculo del servidor, el servidor considera que el cliente está autenticado.
Tenga en cuenta que, dado que el cliente no puede falsificar H(R,Q), H(R,Q) actúa como una cookie (y, por lo tanto, podría implementarse realmente como una cookie).
Otra edición:
La edición anterior del protocolo es incorrecta, ya que cualquiera que haya observado H(R,Q) parece poder reproducirlo con el hash correcto. El servidor tiene que recordar qué R ya no están actualizados. Estoy enviando esta respuesta a CW para que puedan editar esto y encontrar algo bueno.
Sección de Reseñas y Valoraciones
Si te ha resultado de provecho este artículo, agradeceríamos que lo compartas con el resto entusiastas de la programación de esta manera contrubuyes a difundir nuestro contenido.