¿Cómo puedo almacenar la información de forma segura cuando no puedo usar crypt o un hash?

Question

¿Cómo puedo almacenar la información de forma segura cuando no puedo usar crypt o un hash?

#1 de LateralFractal (1 votos)

2

Estoy creando una aplicación para Google Glass (técnicamente es Glassware , pero como sea). El usuario realizará los siguientes pasos cuando realice la configuración de la Cristalería:

Vaya a mi sitio web, redirigido a través de la página de Cristalería.
Redirige a la página de Google OAuth para que puedan iniciar sesión.
Redirigir nuevamente a mi URI de redireccionamiento OAuth (una forma elegante de decir la página de destino).
Se le pedirá que vaya a un sitio web de terceros (algo como Facebook, Twitter o Instagram, todavía no está seguro).
Ir a través de la danza OAuth o una danza de autenticación para obtener una clave API / clave OAuth.
Agradece que todo haya terminado.

Ahora, lo que tengo en mis manos es un par de tokens API / OAuth, un ID de usuario internamente y la ID de Google de un usuario. Posiblemente podría tener algunos puntos de datos más, como CreationDate y esas cosas, pero ninguno tan importante como estos datos.

Ahora que tengo todos estos datos, es hora de almacenarlos. Probablemente se almacenará en una base de datos como MySQL. Ya que tengo todos estos datos importantes sobre un usuario, ¿cómo puedo asegurar que los hackers no puedan acceder a ellos? No puedo usar un hash o crypt de PHP, ya que el usuario no ingresará sus Contraseña cada vez que necesito usar sus tokens. De hecho, el usuario tendrá un nombre de usuario y una contraseña no específicos para mi servicio. Me doy cuenta de que esto hace que sea difícil de asegurar, sin embargo, almacenar todo esto como texto sin formato parece inseguro ... ¿o no?

Entonces, ¿cómo aseguro los tokens de un usuario cuando el usuario no tiene una contraseña asociada con mi servicio y el usuario no va a iniciar sesión en el servicio cada vez que necesito usar sus tokens?

passwords php

pregunta hichris123 04.03.2014 - 23:57

fuente

1 respuesta

Lea otras preguntas en las etiquetas passwords php

Strange TLSv1.2 Handshake Función de hash sensible a la ubicación (LSH) que coincide aproximadamente con las contraseñas antiguas

score 1 · Answer 1

Haga que la aplicación cliente envíe una clave de cifrado generada aleatoriamente durante el proceso de autenticación inicial. Dependiendo de la frecuencia con la que desee que el usuario inicie sesión, la clave podría generarse para una sola sesión o globalmente para el dispositivo cliente.

Para la aplicación del servidor, mantenga dos copias de los tokens de autenticación: la primera copia se cifra mediante la clave del cliente para la persistencia, la segunda no está encriptada pero es transitoria en la memoria del servidor. La segunda copia transitoria se elimina después de que el cliente no se haya escuchado o se haya desconectado / desinstalado.

De esta manera, un pirata informático con acceso a dispositivo cliente no tiene los tokens de OAuth y solo puede abusar de su servicio específico. Un pirata informático con acceso al servidor no tiene clave de descifrado y, por lo tanto, los tokens OAuth son inútiles.

Sin embargo, un pirata informático podría simplemente alterar la aplicación del servidor para cosechar futuros tokens OAuth. Por lo tanto, el servidor web debe prohibir las implementaciones de aplicaciones de intercambio en caliente sin reiniciar y requerir una contraseña proporcionada por la consola para el certificado SSL del servidor en el arranque, que la aplicación cliente comprueba explícitamente en lugar del almacén de confianza CA estándar para todos.