2011-10-24 12 views
12

Estoy creando una aplicación web que debe funcionar sin conexión. El sistema está diseñado para capturar transacciones de ventas. La mayor parte de la parte "fuera de línea" es bastante sencilla: solo necesito almacenar datos localmente y sincronizarlos cuando vuelva a la red. Hasta aquí todo bien.Autenticación de usuario en aplicaciones web sin conexión

El problema es con la autenticación. La aplicación se ejecutará en una máquina compartida con una única cuenta de usuario del sistema operativo. Si estoy fuera de línea, ¿cómo autentico al usuario?

Los propios usuarios no tienen datos privados que deba segmentar (es decir, no tengo que protegerlos entre sí en el cliente). Necesito poder validar su contraseña para poder permitir el ingreso a diferentes usuarios durante el día, incluso si la conexión no funciona.

Un enfoque que estoy pensando implica el almacenamiento en caché de los hashes de contraseña en el lado del cliente en un IndexedDB. Solo un conjunto limitado de usuarios podrá iniciar sesión desde una máquina compartida específica, por lo que no necesitaré almacenar en caché toda la base de datos de contraseñas localmente. Suponiendo que tengo una buena política de contraseñas (requisitos de complejidad y caducidad) en su lugar y los hashes en sí mismos son seguros (bcrypt), ¿qué tan horrible de una idea es esta?

¿Tengo alguna otra opción?

+0

Por lo que he leído, la expiración de la contraseña puede ser más dañina que útil: http://www.cryptosmith.com/node/218 Aunque, ese puede no ser el caso si estás exponiendo tu base de datos. –

Respuesta

9

Así es como funcionan Windows (y otros sistemas) cuando la máquina no puede alcanzar el controlador de dominio (por ejemplo, lleva su computadora portátil al avión y necesita iniciar sesión en su computadora portátil sin conectividad). Su máquina ha anotado un caché de su par de nombre de usuario | contraseña y le permitirá ingresar a través de esas credenciales, incluso si está fuera de línea.

Creo que, en general, almacenar los hashes de nombre de usuario | contraseña es bastante seguro, suponiendo que los hash de manera razonable (por ejemplo, usar una sal, usar un IV, etc.). Una exposición que querrá pensar es tener el archivo hash "escape". Si se trata de datos confidenciales, querrá ser extremadamente cuidadoso, y esto puede que ni siquiera sea aceptable, pero si no se trata de datos súper confidenciales, entonces probablemente esté bien: con un buen hashing, creo que debería ser razonable (pero desde luego no Completamente seguro.

1

Quizás esto no tiene nada que ver, pero utilizo este enfoque en mi proyecto nodejs. Cuando un usuario se autentica por nombre de usuario y contraseña, se le asigna una clave de API única utilizada solo para esta sesión en particular.

Cada usuario puede tener solo una clave de API.

Esta clave API se agrega a cualquier solicitud hecha al servidor, para autenticar al usuario.

Cuando el usuario cierra la sesión, se elimina la clave de la API. Además, la clave API se puede purgar en el servidor, lo que hace que el usuario se autentique en el servidor una vez más.

Puedo proporcionar enlaces a los programas de código abierto de nodejs que utilizan este enfoque si lo desea.

+0

Sin duda estaría interesado, proporcione un enlace si todavía está dispuesto a hacerlo. – GojiraDeMonstah

+0

dando esta clave de API, un marco de tiempo también es una buena práctica – Serdar

+0

esta publicación es un buen recurso para leer http://www.staticapps.org/articles/authentication-and-authorization – Serdar

Cuestiones relacionadas