Actualmente estoy trabajando en un proveedor PHP OpenID que funcionará sobre HTTPS (por lo tanto, cifrado con SSL).
¿Es incorrecto que transmita la contraseña como texto sin formato? HTTPS en teoría, no se puede interceptar, así que no veo nada malo. ¿O es esto inseguro en algún nivel y no veo esto?
Respuestas:
Es seguro. Así es como funciona toda la web. Todas las contraseñas en los formularios siempre se envían en texto sin formato, por lo que depende de HTTPS protegerlas.
Aún debe asegurarse de enviarlo mediante solicitud POST, no GET. Si lo envía a través de una solicitud GET, se puede guardar en texto plano en los registros del historial del navegador del usuario o en los registros de acceso del servidor web.
Si HTTP está deshabilitado y solo usa HTTPS, entonces realmente no está transmitiendo la contraseña como texto sin formato de todos modos.
Hash del lado del cliente. ¿Por qué? Déjame contarte un pequeño experimento. Camine hasta la computadora en la cafetería de la empresa. Abra el navegador en la página de inicio de sesión del sitio web de la empresa (https). Presione F12, haga clic en la pestaña de red, marque el registro persistente, minimice la consola pero deje la página web abierta para iniciar sesión. Siéntese y almuerce. Observe cómo empleado tras empleado inicia sesión en el sitio web de la empresa y cómo un buen trabajador se desconecta cuando termina. Termine el almuerzo, siéntese en la computadora, abra la pestaña de red y vea cada nombre de usuario y contraseña en texto sin formato en el formulario bodys.
Sin herramientas especiales, sin conocimientos especiales, sin hardware de piratería sofisticado, sin keyloggers, solo el viejo F12.
Pero bueno, sigue pensando que todo lo que necesitas es SSL. Los malos te amarán por eso.
Tomemos algunas notas a las respuestas anteriores.
Primero, probablemente no sea la mejor idea usar algoritmos hash del lado del cliente. Si su contraseña está salada en el lado del servidor, no podrá comparar hashes (al menos no si no almacena el hash del cliente en la base de datos en una de las capas de hash de la contraseña, que es la misma o peor). Y no desea implementar el algoritmo hash utilizado por la base de datos en el lado del cliente, sería una tontería.
En segundo lugar, el intercambio de claves criptográficas tampoco es ideal. El MITM podría teóricamente (considerando que tiene un certificado raíz instalado en el cliente) cambiar las claves criptográficas y cambiar con sus propias claves:
Conexión original (sin considerar tls) de un servidor teórico que intercambia claves:
El cliente solicita claves públicas> el servidor contiene las claves privadas, genera claves públicas para el cliente> el servidor envía claves públicas al cliente
Ahora, en una pista teórica MITM:
El cliente solicita claves públicas> MITM genera claves privadas falsas > El servidor contiene las claves privadas, genera claves públicas para el cliente> MITM recibe las claves públicas del servidor original, ahora, podemos enviar nuestras claves públicas falsas al cliente y Siempre que una solicitud provenga del cliente, descifraremos los datos del cliente con las claves falsas, cambiaremos la carga útil (o la leeremos) y encriptaremos con las claves públicas originales > MITM envía claves públicas falsas al cliente.
Ese es el punto de tener un certificado CA confiable en TLS, y así es como recibe un mensaje del navegador que advierte si el certificado no es válido.
En respuesta al OP: en mi humilde opinión no puedes hacer eso, porque tarde o temprano alguien querrá atacar a un usuario de tu servicio e intentará romper tu protocolo.
Sin embargo, lo que puede hacer es implementar 2FA para evitar que las personas intenten iniciar sesión con la misma contraseña. Sin embargo, tenga cuidado con los ataques de repetición.
No soy bueno con la criptografía, corrígeme si me equivoco.
Los otros carteles son correctos. Ahora que está utilizando SSL para cifrar la transmisión de la contraseña, asegúrese de aplicar un algoritmo hash con un buen algoritmo y sal para que también esté protegida cuando esté en reposo ...
El ejemplo de @CodeDog tiene problemas ...
Sí, puedo creer que los usuarios iniciarán sesión en una caja de cafeteria. Si está capturando registros de una cafetería corporativa, entonces usted es la brecha de seguridad. Las cajas de cafeterías corporativas deben configurarse deshabilitadas, por ejemplo, sin términos, sin registradores, sin acceso remoto, etc. Para evitarlo, el hacker interno.
El ejemplo es bueno para la seguridad del acceso a la computadora y no está realmente relacionado con la seguridad de la red. Se proporciona como justificación para el hash del lado del cliente, pero si tiene acceso a una computadora, puede usar un registrador de pulsaciones de teclas y omitirlo. El hash del lado del cliente es nuevamente irrelevante. El ejemplo de @CodeDog es un truco de acceso a la computadora y requiere técnicas diferentes a las de la capa de red.
Además, un pirateo informático público está protegido paralizando el sistema de las amenazas, como se mencionó anteriormente. por ejemplo, use un Chromebook para una computadora de cafetería pública. Pero eso se pasa por alto mediante un truco físico . Durante las horas libres, vaya a la cafetería y configure una cámara secreta para grabar las pulsaciones de teclado de los usuarios. Entonces no importa si la computadora de la cafetería está dañada, O qué tipo de cifrado se utiliza.
capa física -> capa de computadora -> capa de cliente -> capa de red -> capa de servidor
Para redes, no importa si aplica hash en el lado del cliente porque la capa https / ssl cifrará la contraseña simple. Como otros mencionan, el hash del cliente es redundante si el TLS es seguro.