Autenticación basada en token - Asegurar el token

El "token de autenticación" funciona de la forma en que el servidor lo recuerda.

Un token genérico es una cadena aleatoria; el servidor mantiene en su base de datos una asignación de tokens emitidos a nombres de usuarios autenticados. Los tokens antiguos se pueden eliminar automáticamente para evitar que la base de datos del servidor crezca indefinidamente. Tal token es lo suficientemente bueno para la seguridad siempre y cuando un atacante no pueda crear un token válido con probabilidad no despreciable, un "token válido" es "un token que está en la base de datos de tokens emitidos". Es suficiente que los valores del token tengan una longitud de al menos 16 bytes y se produzcan con un PRNG criptográficamente sólido (por ejemplo, /dev/urandom , CryptGenRandom() , java.security.SecureRandom ... dependiendo de su plataforma).

Es posible descargar el requisito de almacenamiento en los propios clientes. En el párrafo anterior, ¿qué "memoria" debe tener el servidor de un token? A saber, el nombre de usuario y la fecha de producción del token. Por lo tanto, crea tus tokens de esta manera:

• El servidor tiene una clave secreta K (una secuencia de, digamos, 128 bits, producida por un PRNG criptográficamente seguro).
• Un token contiene el nombre de usuario ( U ), la hora de emisión ( T ) y un comprobación de integridad con clave calculada sobre U y T (juntas), con la clave K (de forma predeterminada , use HMAC con SHA-256 o SHA-1).

Gracias a su conocimiento de K , el servidor puede verificar que un token dado, enviado por el usuario, sea uno de los suyos o no; pero el atacante no puede falsificar esos tokens.

La respuesta a la que te vinculas se ve así, excepto que se trata de encriptación en lugar de MAC, y eso es:

1. confundido;
2. confuso;
3. potencialmente inseguro;

porque el cifrado no es MAC.

En resumen, deberías usar un token aleatorio de una sola vez de fuerza criptográfica y codificarlo en la base de datos.

El token

• debe permitirse su uso una sola vez,
• debe solo ser utilizable para el usuario para el que fue creado,
• debe solo enviarse a través de HTTPS,
• debería tener una fecha de caducidad (por ejemplo, 7 días).

Una vez que el usuario inicia sesión con el token, no es válido y se debe crear un token nuevo para el usuario. En el caso de un token caducado, se debe hacer que el usuario inicie sesión nuevamente, utilizando sus credenciales reales.

Se puede encontrar una descripción más definitiva y extensa de estas reglas en la parte 2 de La guía definitiva para la autenticación de sitios web basada en formularios :

  

Las cookies de inicio de sesión persistentes (funcionalidad "recordarme") son una zona de peligro; por un lado, son tan seguros como los inicios de sesión convencionales cuando los usuarios entienden cómo manejarlos; y, por otro lado, representan un enorme riesgo para la seguridad en manos de la mayoría de los usuarios, que los usan en computadoras públicas, se olvidan de cerrar sesión, no saben qué son las cookies o cómo eliminarlas, etc.

     

[...◆

     

Siga el artículo de "Mejores prácticas" de Charles Miller . No se sienta tentado a seguir las Mejores prácticas "mejoradas" vinculadas al final de su artículo. Lamentablemente, las "mejoras" del esquema se pueden frustrar fácilmente (todo lo que un atacante debe hacer cuando robar la cookie "mejorada" es recordar eliminar la anterior. Esto requerirá que el usuario legítimo vuelva a iniciar sesión, creando un nuevo identificador de serie y dejando el robado válido).

     

Y, podría usar los tokens para iniciar sesión en cualquier cuenta, como si fueran combinaciones de contraseña de inicio de sesión de texto simple. Por lo tanto, use el hashing con sal fuerte (bcrypt / phpass) cuando almacene tokens de inicio de sesión persistentes.

Actualización: Lo siento, entendí mal la pregunta. El método que vinculate parece razonable, pero no te protegerá de los ataques de repetición o de la persona en el medio. Deberías usar SSL a su lado.

Un servicio web de API RESTful pura debe usar las características estándar del protocolo subyacente:

1. Para HTTP, la API REST debe abarcar y cumplir con los encabezados, códigos de estado y métodos estándar de HTTP existentes. Agregar un nuevo encabezado HTTP viola los principios de REST.

2. Los servicios RESTful DEBEN ESTAR SIN ESTADO. Cualquier truco, como la autenticación basada en token que intenta recordar el estado de las solicitudes REST anteriores en el servidor viola los principios de REST.

Línea inferior: para fines de autenticación / autorización, debe usar el encabezado de autorización HTTP. Y debe agregar el encabezado del esquema de autorización HTTP específico en cada solicitud posterior que deba autenticarse.

He desarrollado un servicio web RESTful para la aplicación Cisco Prime Performance Manager. Busque en Google el documento de la API REST de Cisco Prime Performance Manager que escribí para esa aplicación para obtener más detalles sobre el cumplimiento de la API RESTFul; consulte a continuación. Para esta aplicación, hemos optado por utilizar el esquema de autorización HTTP "Básico" para autenticar y autorizar las solicitudes. Y, obviamente, estamos utilizando HTTP para cifrar todos los datos en tránsito desde el cliente al servidor cuando usamos la Autorización HTTP.

enlace