Autenticación personalizada en una API RESTful: ¿Funcionará esto?

Navega tus respuestas
4

Me preguntaba si esta sería una forma razonable de escribir un método de autenticación personalizado para una API RESTful. Parece moderadamente seguro, pero quizás estoy muy equivocado aquí.

1) El correo electrónico y la contraseña se envían a través de HTTPS a mi servidor.

2) El servidor almacena el correo electrónico y ejecuta la contraseña a través de un hash SHA512 con un salt aleatorio de 256 bits. La contraseña con hash y con sal se almacena en la base de datos.

Así que ahora tenemos: 

email = [email protected]

password = OHqhuewQclakufEjUbZMbowJKEGcvEBz,51c6a3cb58e10754f76e334de064a9dede7875141e1ce0233e3ff14fd7be98a4d5b8fc1c5ab871cb3b1d6b0c9f8073bc3558308511fc4fd6bd049aed5e58a9a4

3) Genere un token aleatorio con un tiempo de vida (muy aleatorio y grande), guárdelo en la base de datos y luego vincule ese token aleatorio a ese usuario autenticado específico.

4) Envío el token de vuelta al cliente a través de HTTPS (web, Android o iOS), por lo que se almacena en cookies o SharedPrefs o lo que sea.

5) Ahora, el cliente envía el token con cada solicitud. Luego, el servidor puede verificar el valor del token almacenado en caché con el que recibe cada vez para asegurarse de que el servidor siempre sepa quién realiza las solicitudes.

¿Esto parece razonable y seguro? El problema que creo que surge aquí es si la base de datos de tokens alguna vez se ve comprometida. ¿Hay tal vez alguna forma de endurecer esa parte?

    
pregunta Kris 14.12.2015 - 18:23
fuente

3 respuestas

4

Parece razonable si el paso 5 también se realiza a través de HTTPS. En cuanto a qué hacer si sospecha que los tokens se han comprometido, puede almacenar una fecha de caducidad para cada token y obligar a los usuarios a volver a autenticarse después de que el token haya caducado. Al sospechar una infracción, simplemente expira todas las fichas inmediatamente.

    
respondido por el TTT 14.12.2015 - 19:22
fuente
2

Tu idea de token está bien, pero el hashing de la contraseña es horrible. Estás usando un hachís rápido, la sal ayuda un poco, pero eso es inseguro; debe utilizar una función de hashing lento especialmente diseñada para contraseñas como bcrypt.

La mayoría de los marcos web proporcionan funciones de autenticación listas para usar que utilizan los métodos más seguros disponibles, así que no reinvente la rueda y, en su lugar, confíe en el código bien probado y ampliamente utilizado. ¿Aún no usas un framework? Piense en usar uno, le ahorrará bastante tiempo.

    
respondido por el André Borie 14.12.2015 - 22:12
fuente
0

  1. Como André Borie ya dijo: Use un algoritmo de hashing diseñado para contraseñas. Tenga en cuenta que las contraseñas que está almacenando no son suyas. Son información muy sensible proporcionada por el usuario. Puede recomendar al usuario que no reutilice la contraseña, pero es incorrecto suponer que la cumplirán. Además, lo culparán si su servicio se ve comprometido y las contraseñas se descifran.

  2. Considere encapsular la autenticación en un servicio adicional que está separado de su API. Esto puede ayudar a reducir la superficie de ataque.

  3. Puede encapsular el almacenamiento de la sal en otro sistema al que no se puede acceder desde otros hosts. Allí se crea un servicio que genera una sal para un ID de usuario determinado o cualquier otra información que sea única para una cuenta. Si su base de datos se descarga, las sales no forman parte de ella, lo que hace que el craqueo sea casi imposible. Para poder acceder al Salt, un atacante necesitaría tener privilegios de ejecución de código y la información de autenticación para su servicio. (Suponiendo que el atacante ya sepa que está utilizando sales externas)

respondido por el Noir 15.12.2015 - 11:02
fuente

Lea otras preguntas en las etiquetas

¿Con qué frecuencia debo buscar puertos abiertos desconocidos? ¿Cómo debo bloquear los nombres de dominio no deseados? [duplicar]