Autenticación sin inicio de sesión y contraseña en aplicaciones móviles

Trabajo como 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: deberá cumplir con lo siguiente:

1. El token caduca en algún momento
2. El token no se puede modificar en tránsito entre el cliente y el servidor.
3. El usuario no puede modificar el token.

  

El token caduca en algún momento

Este requisito es el más fácil. 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, luego rechace el token porque ha caducado.

  

El token no se puede modificar en tránsito entre el cliente y el servidor

A medida que esté utilizando TLS, (es de esperar que la versión 1.2 y la actualización a 1.3 cuando se finalice) este problema ya se haya 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 usar una firma digital con PKI. No use SHA 1 como función de hash porque este algoritmo es INSECURE. La aplicación de la función de hash a los resultados del token de acceso en un resumen del mensaje. El resumen del mensaje se encripta utilizando la clave privada que solo el usuario conoce. Una vez que la credencial se descifra en el servidor utilizando la clave pública del usuario, si el mensaje resultante coincide con las credenciales del servidor, se garantiza que no se realizó ninguna modificación del token de acceso por parte del usuario.

El método anterior garantiza la C: confidencialidad y I: requisitos de integridad de la tríada CIA de seguridad. El no repudio (el usuario no puede negarlo 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 tus otras preguntas:

  

¿Debo cifrar el token de acceso localmente cuando esté almacenado?

Sí, deberías. Lo anterior corresponde a los datos en tránsito, pero no está en reposo . Si un pirata informático comprometiera la máquina cliente local, él o ella puede robar fácilmente un token de texto simple y luego hacerse pasar por el propietario legítimo.

  

¿Cómo debo cifrar?

Debería usar un algoritmo de cifrado fuerte como AES o RSA. Elija una longitud de clave larga (por ejemplo, 256) para maximizar la seguridad.

  

¿Esto es seguro contra un atacante remoto o local?

Una cosa en la que puedo pensar es en un usuario malintencionado que reproduce el token de acceso para hacerse pasar por el cliente válido.
Para mitigar esto, puedes usar la marca de tiempo. Otra opción podría ser obtener un nuevo token de acceso del servidor después de cada solicitud.

  

¿Cuál sería la mejor manera de almacenar el token de acceso localmente? ¿Debo cifrarlo localmente? ¿Cómo debo cifrar? ¿Debo cifrarlo en la base de datos del servidor?

Puede funcionar mantener el token de acceso como un valor cifrado en el almacenamiento local. No soy un experto en aplicaciones móviles, pero creo que tiene acceso a una base de datos en aplicaciones móviles. Puede almacenar los datos encriptados allí. Al mismo tiempo, mantener el token cifrado en el servidor también es una buena idea.

  

¿Esto es seguro contra un atacante remoto o local?

Para lograr los objetivos que menciona, realmente desea que el token esté cifrado en el lado del servidor con una clave exclusiva del servidor. Para acortar la historia (er), es muy difícil hacerlo correctamente como desarrollador novato .

Hacer esto correctamente requiere considerar protecciones contra:

• Maleabilidad : la capacidad del usuario para modificar (o extender) el token, ya sea que el usuario pueda leerlo o no. Esto normalmente se logra con un HMAC .
• Reproducir : la capacidad del usuario (u otra persona que obtiene acceso al token) de reutilizarlo en otro contexto. Esto se puede hacer con fechas de vencimiento o más completamente con tokens de un solo uso (que se actualizan con cada uso), y cada solución requiere diferentes recursos del lado del servidor.
• Descifrados o correlaciones de fuerza bruta : se basan en ataques como tablas de arco iris . Estos se suelen mitigar con sales y pimientos / padding.

También debe preocuparse por rotar la clave del servidor con regularidad, mantener la compatibilidad con versiones anteriores de los tokens que generó (por ejemplo, para versiones anteriores de su aplicación) y actualizar el esquema criptográfico subyacente si existe un compromiso (por ejemplo, ¿quieres revocar todos los tokens pendientes en este caso?).

Análisis final

Si desea preparar su propio esquema, le sugiero que colabore con alguien con un fondo de criptografía sólido (y actualizado). Recomendaría una solución enlatada, pero no estoy al tanto de nada que esté disponible de forma gratuita y que sea realmente seguro de plug-and-play.