¿Hay alguna forma de autenticar un cliente HTTP solo una vez?

Question

¿Hay alguna forma de autenticar un cliente HTTP solo una vez?

#1 de symcbean (1 votos)
#2 de David (0 votos)

2

Estoy trabajando en una aplicación que actúa como back-end (API REST) para una extensión de Google Chrome. Se supone que los datos se envían desde y hacia el cliente.

La forma en que funciona es:

Los datos que provienen del cliente están encriptados por la aplicación utilizando AES-256 (usando la clave maestra, busque debajo ) y se almacenan en una base de datos SQLite3.
Los datos que la aplicación envía al cliente se descifran en el back-end y luego se envían a través de un protocolo HTTP.

Nota, la aplicación y la extensión residen en el mismo entorno local, por lo que otras computadoras en la red no pueden acceder a ella. Es por eso que los datos se transfieren en texto sin formato en ambos casos.

Hay algunas restricciones:

Puede haber varios clientes enviando solicitudes al back-end. Todos están controlados por la misma persona.
Hay un formulario de inicio de sesión en el cliente y solo se requiere una clave maestra. Una vez que se envía el formulario, se supone que la clave se envía al back-end y el cliente se autentica, es decir, al compararlo con el (cifrado mediante PBKDF2) en la base de datos.

El problema El problema es que no quiero almacenar la clave maestra de forma persistente en el cliente (Javascript), ya que cualquiera puede acceder fácilmente a la computadora. Si era posible autenticarse solo una vez, enviando la clave maestra a través del protocolo a la aplicación y luego retírela del cliente.

Entonces, la pregunta es ¿cuál sería la solución óptima?

authentication http aes javascript

pregunta Andrius 19.01.2018 - 17:14

fuente

2 respuestas

Lea otras preguntas en las etiquetas authentication http aes javascript

Cualquier vulnerabilidad de seguridad en PHP fsocketopen descubrimiento de Windows a través de puertos WMI no seguros

score 1 · Answer 1

¿Hay alguna forma de autenticar un cliente HTTP solo una vez?

No, porque HTTP no tiene estado.

los datos que provienen del cliente están encriptados ... usando la clave maestra

Tanto el contenido del navegador como el contenido del servidor es la aplicación. ¿Dónde está ocurriendo el cifrado?

Los datos que la aplicación envía al cliente se descifran en el back-end y luego se envían a través de un protocolo HTTP

Bien, entonces, cuando dices la aplicación, ¿realmente te refieres al lado del servidor?

Parece que nunca hay ningún requisito para almacenar la "clave maestra" en el cliente.

iniciar sesión en el cliente y solo requiere una clave maestra

¿También utiliza la clave de cifrado como token de autenticación? De Verdad? Esperas que los usuarios escriban algo como

c48bb691eb5e2f609192ed5a981c6f8745896aa968604c1cdf70cb57ebc0d421

cada vez que inician sesión? Apuesto a que les está permitiendo que elijan contraseñas / claves realmente simples o que las están almacenando en algún lugar.

Simplemente puede almacenar la clave maestra del lado del servidor en una variable de sesión HTTP. Pero si esto realmente es una clave "maestra", entonces los clientes / usuarios no deberían tener visibilidad de ella. Debe separar la autenticación del cifrado.

Hay varias cosas que podría hacer con el almacenamiento local, un segundo servidor, cifrar la clave maestra con la contraseña del usuario para protegerla, pero sin saber mucho más sobre la plataforma es imposible recomendarlo (y se vuelve demasiado complejo para una discusión aquí).

score 0 · Answer 2

es decir, comparándolo con el de la base de datos.

...

El problema es que no quiero almacenar la clave maestra de forma persistente en el cliente (Javascript), ya que cualquier persona que pueda acceder a la computadora puede buscarla fácilmente.

Dado que has establecido eso:

La clave maestra se almacena en la base de datos.
La base de datos reside en la misma computadora que el cliente.
Está preocupado por los atacantes locales que tienen acceso a la computadora.

Ya has perdido. La llave maestra puede ser robada de la base de datos. No estoy seguro de por qué está convencido de que almacenarlo en, por ejemplo, LocalStorage es menos seguro que la base de datos.

Defender contra un atacante con acceso físico que puede ejecutar código en su máquina (que es lo que a mí me parece "cualquier otra persona que pueda acceder a la computadora") es básicamente imposible. Lo mejor que puede obtener son cuentas de usuarios locales independientes con algún tipo de cifrado por usuario para proteger los datos, usando claves respaldadas por el TPM y un entorno de inicio seguro, pero de repente ha pasado de la construcción de una extensión de Chrome a la necesidad de asegurar todo el entorno.