Pregunta:
Estoy comenzando en el desarrollo de aplicaciones y estoy pensando en el flujo de inicio de sesión de la primera aplicación. Algunas otras aplicaciones como Whatsapp y Choque de clanes no requieren ningún proceso de registro o inicio de sesión para conectarse. Entonces, pensé en esta metodología:
- Si es la primera vez que inicia la aplicación, enviará un evento "Registrarse" al servidor con un nombre de usuario que elija el usuario.
- El servidor comprobará si el nombre de usuario ya está en uso, y si no, creará una cuenta en la base de datos con el nombre de usuario y generará un token de acceso de 64 caracteres.
- El servidor enviará el token de acceso al cliente.
- El cliente almacenará el token de acceso para más solicitudes de inicio de sesión y será la única forma de autenticación.
Todo el proceso de conexión sería a través de TLS a un servidor socket.io.
¿Es esto seguro contra un atacante local o remoto? ¿Cuál sería la mejor forma de almacenar el token de acceso localmente? ¿Debería cifrarlo localmente? ¿Cómo debo cifrar? ¿Debería cifrarlo en la base de datos del servidor?
Respuesta:
Trabajo como un profesional de seguridad de TI (Auditor de TI), por lo que puedo responder por experiencia.
Primero, definiré un token seguro. Para que el token de acceso sea seguro: debe cumplir con lo siguiente:
- El token expira en algún momento
- El token no se puede modificar en tránsito entre el cliente y el servidor.
- El usuario no puede modificar el token.
El token expira en algún momento
Este requisito es el más sencillo. Especifica una fecha en la que este token ya no será válido, en el lado del servidor. Si la fecha de inicio de sesión> fecha de vencimiento del token, rechace el token por haber vencido.
El token no se puede modificar en tránsito entre el cliente y el servidor
Como está utilizando TLS (con suerte, la versión 1.2 y la actualización a 1.3 cuando esté finalizada) este problema ya debería estar resuelto. TLS proporciona confidencialidad , lo que garantiza que el token de acceso no se divulgue sin autorización a un tercero.
El usuario no puede modificar el token
Este requisito es el más difícil. Para acompañar esto, necesitaría utilizar una firma digital con PKI. No use SHA 1 como función hash porque este algoritmo es INSEGURO. La aplicación de la función hash al token de acceso da como resultado un resumen del mensaje. Luego, el resumen del mensaje se cifra con la clave privada que solo el usuario conoce. Una vez que las credenciales se descifran en el servidor utilizando la clave pública del usuario, si el mensaje resultante coincide con las credenciales del servidor, entonces se garantiza que no se realizó ninguna modificación del token de acceso por parte del usuario.
El método anterior garantiza los requisitos C – confidencialidad e I – Integridad de la tríada de seguridad CIA. El no repudio (el usuario no puede negar que son sus credenciales) también está garantizado debido a que la clave pública del usuario puede descifrar el mensaje cifrado recibido.
Para responder algunas de sus otras preguntas:
¿Debo cifrar el token de acceso localmente cuando se almacena?
Si deberías. Lo anterior se refiere a datos en tránsito, pero no en reposo . Si un pirata informático comprometiera la máquina del cliente local, puede robar fácilmente un token de texto sin formato y luego hacerse pasar por el propietario legítimo.
¿Cómo debo cifrar?
Debe utilizar un algoritmo de cifrado sólido como AES o RSA. Elija una longitud de clave larga (p. Ej., 256) para maximizar la seguridad.