¿Cómo aseguro la autenticación pero no la carga útil?
https://stackoverflow.com/questions/600329
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Estoy buscando un protocolo HTTP existente para asegurar la autenticación pero no la carga útil que sigue. Quiero que el servidor almacene el nombre de usuario, la contraseña con hash y la sal diferente por usuario.
La autenticación HTTP Digest falla estos requisitos porque todas las cuentas usan el mismo salt. SSL falla porque encripta toda la conexión.
Editado para agregar:
Esto es para un cliente de escritorio que habla con un servicio web (sin navegador)
Solución
¿Por qué no solo tiene su mecanismo de autenticación protegido por SSL y luego reenvíe al resto de su aplicación que se ejecuta bajo HTTP normal?
Otros consejos
El esquema popular es tener el formulario de inicio de sesión protegido por SSL, mientras que el resto del sitio no utiliza SSL. Ver, por ejemplo, sitios de redes sociales populares.
¿Qué hay de OpenID? ¿Hay alguna razón por la que tenga que almacenar información de autenticación?
Editado para agregar
Lo sentimos, no me di cuenta de que era una aplicación de escritorio. ¿Qué hay de OAuth ?
¿Hay alguna forma de que pueda estructurar la URL de solicitud original para indicar al usuario? Luego, el servidor podría responder con un reino diferente (actuando como " sal ") para cada usuario en la respuesta de autenticación del resumen HTTP. Por ejemplo, solicitar las URL del formulario http://user.y.com/service o http://www.y.com/user/service daría lugar a una respuesta de desafío como:
WWW-Authenticate: Digest realm="user@y.com", nonce="oqa9hvq49krprkphtqc"
¿Puede explicar qué impulsa el " sin cifrado " ¿mandato? Si está sujeto a ataques de intermediario, debe proteger la integridad de toda la solicitud. Allí, SSL sería muy útil. Si no puede tener cifrado, ¿sería aceptable utilizar SSL con un conjunto de cifrado no cifrado?
