La autenticación básica HTTP no se usa mucho en las conexiones de navegador-servidor porque implica, en el lado del navegador, una ventana emergente de inicio de sesión controlada por el navegador que es invariablemente fea. Por supuesto, esto no se aplica a las conexiones servidor-servidor, donde no hay usuarios humanos que observen la fealdad, pero contribuye a un clima general de desconfianza y desuso para la autenticación básica.
También, en la década de 1990, antes de los días de SSL, el envío de contraseñas de texto simple a través del cable se consideraba un delito de tiro, y, en su locura, las personas consideraban que los protocolos de desafío-respuesta como HTTP Digest fueron suficientes para garantizar la seguridad. Ahora sabemos que no es así; independientemente del método de autenticación, el tráfico completo debe estar al menos criptográficamente vinculado a la autenticación para evitar el secuestro por parte de atacantes activos. Así que SSL es obligatorio . Pero cuando SSL está en vigor, enviar la contraseña "tal cual" en el túnel SSL está bien. Entonces, para resumir, la autenticación básica en SSL es lo suficientemente fuerte para propósitos serios, incluidos los códigos de lanzamiento nuclear e incluso asuntos relacionados con el dinero.
Uno todavía debe señalar que la seguridad se basa en la imposibilidad de los ataques de Man-in-the-Middle que, en el caso de SSL (como se usa comúnmente) se basa en el certificado del servidor. El cliente SSL (otro servidor en su caso) DEBE validar el certificado del servidor SSL con mucho cuidado, incluida la verificación del estado de revocación mediante la descarga de la CRL correspondiente. De lo contrario, si el cliente es redirigido a un servidor falso, el propietario del servidor falso aprenderá la contraseña ... En ese sentido, el uso de algo parecido a HTTP Digest agrega un nivel adicional de mitigación en caso de que la situación ya se haya puesto bastante mal, porque incluso con HTTP Digest, un servidor falso que realiza un MitM aún puede secuestrar la conexión en cualquier momento.
Si vamos un poco más lejos, podemos notar que al usar la autenticación basada en contraseña, realmente queremos la autenticación mutua basada en contraseña. Lo ideal es que el cliente SSL y el servidor SSL se autentiquen entre sí en función de su conocimiento de la contraseña compartida. Los certificados son una complicación innecesaria; teóricamente, el cliente y el servidor SSL deben usar TLS-PSK o TLS-SRP en esa situación, y evite todo el negocio de certificados X.509 por completo.
En particular, en SRP, lo que el servidor almacena no es la contraseña en sí, sino un derivado de la misma (un hash con una estructura matemática adicional). Uno debe tener en cuenta un punto importante: en el caso de una API web, tanto el cliente como el servidor son máquinas sin humanos involucrados. Por lo tanto, la "contraseña" no necesita ser lo suficientemente débil como para ser recordada por las bolsas de carne. Esa contraseña podría ser, digamos, una secuencia de 25 caracteres aleatorios, con una entropía en el techo. Esto hace que los métodos de hashing de contraseñas habituales (hashing lento, sales) sean poco útiles. Todavía queremos evitar almacenar en la base de datos del servidor (por lo tanto, como una presa de posibles inyecciones de SQL) las contraseñas "tal como están", pero, en ese caso , un simple hash Sería suficiente.
Esto apunta a lo siguiente: idealmente, para que un servidor use una API RESTful para comunicarse con otro, con la autenticación basada en un secreto compartido (fat), la comunicación usará TLS con SRP. Sin certificado, solo hashes almacenados en el servidor. No es necesaria la autenticación básica HTTP o cualquier otra autenticación basada en HTTP, porque todo el trabajo ya se habría producido en el nivel SSL / TLS.
Lamentablemente, el estado actual de implementación de implementaciones SSL / TLS compatibles con SRP generalmente significa que no puede usar SRP todavía. En su lugar, tendrá que usar un SSL / TLS más mundano con un certificado X.509 en el lado del servidor, que el cliente valida debidamente. Siempre que la validación se realice correctamente, no hay ningún problema en enviar la contraseña "tal cual", por ejemplo. como parte de la autenticación básica HTTP.