Para un proyecto en el trabajo, actualmente estoy implementando un servicio web no demasiado grande. Por razones de aprender algo nuevo, intenté convertirlo en un servicio REST, que luego provocó el problema de la autenticación. Finalmente me decidí por la Autenticación básica de HTTP, ya que tiene la ventaja de ser compatible con prácticamente cualquier biblioteca HTTP, aunque yo mismo tuve que implementar el lado del servidor.
Ayer, un colega me sugirió que simplemente enviara la contraseña con hash en lugar del nombre de usuario y la contraseña (eventualmente, solo se podrá acceder al servicio a través de HTTPS, por lo que consideré que la Autenticación básica no es un problema de seguridad, pero dejemos eso de lado por ahora). ). Pero me pregunté qué cambiaría realmente, en cuanto a seguridad.
Enviar la contraseña con hash básicamente significa un hash bcrypt, ya que eso es lo que almacenamos en la base de datos. Lo que significa que primero tendría que enviar al cliente el factor de trabajo y sal para que puedan llegar al mismo hash que tengo en la base de datos. Esto requiere un mecanismo de desafío-respuesta que ya es mucho más complicado de implementar.
Luego está el punto de que la contraseña con hash que el cliente envía para la autenticación funciona esencialmente como una contraseña de texto sin formato, en lo que respecta a la autenticación; y podría ser reproducido fácilmente, si alguien lo toma.
Básicamente, lo que encontré:
- resuelve enviando la contraseña en un formato simple, similar a Digest, a diferencia de Basic
- no resuelve el problema de la repetición (el Compendio lo hace, debido al uso de un nonce) de Basic
- Requiere hash de contraseña en el cliente con un rendimiento menos predecible. P.ej. Es probable que los teléfonos inteligentes requieran factores de trabajo más pequeños que las máquinas de escritorio y los principales consumidores de la API serían los teléfonos inteligentes y las tabletas. Entonces tendríamos que reducir la fuerza de bcrypt en ese caso.
- Sería mucho más complejo de implementar, tanto en el cliente como en el servidor, debido a un esquema personalizado de desafío / respuesta y, por lo tanto, más espacio para errores. Probablemente también va en contra de los principios REST.
¿Me perdí algo? HTTPS resuelve los problemas de la autenticación básica, hasta donde entendí y, por lo tanto, el esquema personalizado no resuelve ningún problema real, aparte del aburrimiento del desarrollador, tal vez. Pero no soy un experto en nada de esto.