¿Qué nivel de seguridad ofrece esta oferta, en comparación con, por ejemplo, un formulario de inicio de sesión HTTPS tradicional que utiliza un nombre de usuario / contraseña que está guardado en el navegador?
Como se ha reunido de otras respuestas, HTTPS oculta la solicitud real en sí. La URL completa no se envía cuando se conecta al servidor; la parte del documento de la url se configura como una solicitud que se parece a esto:
GET /login/reallysecure/thisismypassword
o más tradicionalmente:
POST /login
con los parámetros POST enviados más adelante en la solicitud HTTP, ya sea en forma simple o como parte de un cuerpo de mime multiparte.
Una consideración que probablemente no haya pensado es que los servidores web suelen registran , lo que significa que en cualquier momento tendrá que decir 3 días (ajuste la política de retención de registros) el valor del nombre de usuario inicia sesión a un grep de los administradores de sistemas. Si bien esto es indiscutiblemente irrelevante, ya que una modificación de la aplicación en sí misma podría eliminar las credenciales de inicio de sesión normales sin mucha dificultad, ahora hay un factor de protección adicional: ¿hace una copia de seguridad de sus registros? ¿Qué pasa si estos son robados?
Peor aún, ¿qué sucede si hay una manera de manipular su servidor para devolver los registros a un cliente externo? Esto es una violación masiva de la seguridad, pero a diferencia de devolver una base de datos de contraseñas que, con suerte, utilizan una buena técnica de hashing para mitigar (y es mucho más que mitigar) el impacto de esto, una URL no tiene la misma protección, es simplemente instantánea Acceso a la cuenta en cuestión.
Este es el extremo del lado del servidor del riesgo del lado del cliente que Thomas ya ha resaltado.