¿Es seguro enviar nombres de usuario / contraseñas claros en una conexión https para autenticar a los usuarios?

Sí, esta es la práctica estándar. Hacer algo que no sea esto ofrece una ventaja adicional mínima, si la hay (y en algunos casos puede dañar la seguridad). Siempre que verifique una conexión SSL válida con el servidor correcto, entonces la contraseña está protegida por cable y solo puede ser leída por el servidor. No ganas nada disfrazando la contraseña antes de enviarla, ya que el servidor no puede confiar en el cliente.

La única forma en que la información podría perderse de todos modos es si la conexión SSL se vio comprometida y si la conexión SSL se vio comprometida de alguna manera, el token "disfrazado" sería todo lo que se necesita para acceder a la cuenta, por lo que no Bueno para proteger la contraseña aún más. (Podría decirse que proporciona una protección leve si han usado la misma contraseña en varias cuentas, pero si están haciendo eso, para empezar, no son particularmente conscientes de la seguridad).

Como señaló MyFreeWeb, también hay algunos sistemas elaborados que pueden usar una respuesta de desafío para garantizar que el cliente tenga la contraseña, pero estos son realmente complicados y no se utilizan en absoluto. Tampoco ofrecen una gran ventaja adicional, ya que solo protegen la contraseña para evitar que se comprometa en un servidor hackeado activamente.

No necesariamente.

También debe asegurarse de lo siguiente:

1. Su sitio está protegido contra falsificaciones de solicitudes entre sitios. Utilice la sincronización del patrón de token.

2. Su sitio está protegido contra ataques de fijación de sesión. Cambiar el ID de sesión al iniciar sesión.

3. Si usa cookies de sesión, todo su sitio es HTTPS, no solo la URL de inicio de sesión, y que su cookie de sesión está marcada como segura y solo http (sin acceso a JavaScript). El navegador enviará una cookie de sesión sin cifrar si el usuario escribe http://yoursecuresite (en la misma sesión del navegador).

4. Estás utilizando un protocolo reciente. SSL 1 y 2 están rotos, y 3 también podrían estarlo. Intente utilizar TLS 1.1 o 1.2.

5. Estás usando un cifrado fuerte.

6. No está utilizando la compresión HTTP (GZip) o la compresión TLS. Si su sitio muestra la entrada del usuario (como una entrada de búsqueda), entonces puedo averiguar sus tokens CSRF y su número de cuenta bancaria si está usando compresión.

7. Su servidor no permite la renegociación de clientes inseguros.

8. Está utilizando una clave RSA de 2048 bits (o el equivalente para una clave EC), y nadie más conoce su clave privada.

9. Estás usando HSTS, por lo que el navegador va directo a https, incluso si el usuario escribe http

10. Está utilizando un perfecto secreto hacia adelante, por lo que sus comunicaciones históricas son seguras incluso si su clave privada está filtrada

Siempre que verifique la validez del certificado, esto está perfectamente bien y se realiza todo el tiempo.

La mayoría de los sitios que generalmente se consideran seguros toman prácticamente el enfoque que está describiendo. O dicho de otra manera, simplemente ha descrito el estándar establecido de la industria.

Recomendaría no utilizar un enfoque menos seguro que el que usted menciona. (Ya sea que bcrypt sea mejor o peor que otros hash salados es una discusión en la que no voy a entrar. Simplemente no use nada más débil que un hash salado).

Si desea distinguirse por tener seguridad por encima de los estándares industriales establecidos, hay otras opciones disponibles. Pero requiere un gran esfuerzo en todas las áreas de su aplicación para que valga la pena.

Las áreas relacionadas con la validación de contraseñas que podrían ser más seguras incluyen:

• Protegiendo el servidor contra ataques DoS descargando la mayor parte del cómputo durante la validación al cliente. Es decir. no iterar hashing en el lado del servidor, solo iterar en el lado del cliente y realizar el último paso de hashing en el servidor.
• Protéjase contra las pérdidas de contraseña si el servidor se ve comprometido al obtener un par de claves públicas de la contraseña y nunca deje que el servidor vea la contraseña o la clave secreta.

Como han dicho otros, este es un enfoque estándar.

Sin embargo, para un sitio personal no necesariamente lo seguiría ... Yo usaría el inicio de sesión federado de Facebook, Google o similar, de esa manera no tengo que manejar los problemas del ciclo de vida de la cuenta, y puedo usar Google 2 Factor de autenticación, etc.

Se ahorra tener bastantes formularios y campos en su base de datos, lo que significa menos para salir mal.

Por supuesto, todavía debe autorizar a aquellos usuarios a los que desea acceder mediante una función del proveedor de autenticación, como un grupo de Facebook, algún tipo de lista blanca de usuarios permitidos o un flujo de aprobación de su cuenta. . A veces esto se hace invitando a los usuarios: dándoles una URL que contiene un código de seguridad único y el sistema que lo vincula a un proveedor de Auth en el primer inicio de sesión. Alternativamente los usuarios autetetican y solicitan acceso. Esto los coloca en un estado "pendiente". A continuación, proporciona una interfaz donde puede iniciar sesión y aprobarlos.

HTTPS hace que la solicitud de autenticación no se pueda modificar en tránsito. Sin embargo, para hacerlo "seguro", hay otras cosas que también necesita para hacer las cosas bien. Por ejemplo:

• La página de inicio de sesión completa y todas sus dependencias también deberían haber sido servidas a través de HTTPS, incluso aunque no se esté transmitiendo una contraseña. Servir cualquier parte de él (como JavaScript, CSS o recursos de imagen) a través de HTTP sin cifrar le permitiría a un atacante modificar la apariencia o el comportamiento de la página de inicio de sesión a través de un ataque de intermediario.

  Los navegadores tratarán el contenido mixto de HTTP / HTTPS con diversos grados de sospecha. Algunos simplemente suprimirán el