Cómo implementar de forma segura el inicio de sesión automático

15

He leído muchas, muchas, muchas publicaciones sobre cómo "probablemente estás almacenando contraseñas mal". Siempre se refieren al almacenamiento de contraseñas en un servidor en el que un usuario inicia sesión; básicamente repiten (juegos de palabras) consejos omnipresentes como asegurarse de saltear las contraseñas, etc. Sin embargo, nunca he visto un artículo sobre las mejores prácticas para almacenar contraseñas en un cliente para que el cliente no tenga que iniciar sesión manualmente cada vez que desean iniciar sesión; la función "recordarme".

Muchas piezas de software tienen esta característica, desde navegadores hasta programas como Dropbox.

Hace poco leí un artículo antiguo sobre cómo Dropbox estaba almacenando una ID en su computadora que podía copiar / pegar en otra computadora e iniciar Dropbox e iniciar sesión como el dispositivo del que obtuvo la ID; sin inicio de sesión, nada y acceso completo a la cuenta de Dropbox. Esto parece un diseño realmente estúpido, pero no puedo pensar en una mejor manera de hacerlo.

Ni siquiera estoy seguro de cómo evitar almacenar algo como una cookie en texto sin formato. Si lo encriptas, ¿dónde guardas la clave para descifrarlo?

La única forma en que veo que no se introducen vulnerabilidades de seguridad es eliminar la función de inicio de sesión automático y hacer que el usuario escriba su contraseña cada vez que quiera usar un servicio, pero eso es una lucha de usabilidad y los usuarios se ven obligados a esperar que no tengan que hacerlo.

¿Qué puedo leer sobre el almacenamiento local de credenciales de forma segura para implementar la función de inicio de sesión automático? Si los principios son demasiado simples para un artículo completo, ¿cuáles son? El software en cuestión no debe depender de características que no están presentes en todas las plataformas (como el "llavero" que tienen algunas distribuciones de Linux).

security login

— Jay Simon
fuente

2

Se trata de lo que confías. Si no confía en la máquina, guarde la ID, entonces ese es su problema. Si confías en el llavero, esa es la máxima seguridad que obtendrás. Por supuesto, podría agregar un poco de seguridad personalizada, como detectar hardware del dispositivo o algo así, pero todo es falso, por lo que al final no puede saberlo. Está fuera de tu control. Por supuesto, se excluyen cosas estúpidas como guardar contraseñas de texto claro.

— Luc Franken

@LucFranken, ¿cómo puede confiar en la máquina? Alguien puede explotarte como lo hicieron con Dropbox. También confiaría en el llavero, pero no todas las computadoras tienen uno, y Windows nunca lo hace (AFAIK). Y si está almacenando contraseñas, ¿cómo evita guardarlas en texto sin cifrar? Si los encriptas, ¿dónde guardas la clave para descifrarlo?

— Jay Simon

Ese es exactamente el problema, no puedes confiar en él. El usuario solo puede definir confiar en él. Eso tiene en cuenta que el usuario comprende cuán segura es su máquina. Escribir un virus obteniendo datos de Dropboxes es simplemente posible. Lo mismo con las claves almacenadas localmente y otros datos locales. Puede ayudar a hacerlo más seguro (piense en las aplicaciones que requieren un código de 5 números) pero al final es local y está fuera de su control.

— Luc Franken

@LucFranken, ¿soy solo yo o el inicio de sesión automático parece una característica omnipresente? Si es así, ¿por qué la gente no ha escrito sobre cómo hacerlo bien?

— Jay Simon

Es un requisito muy común, aunque algunos programas empresariales más no lo permiten. Por ejemplo, SalesForce solo permite guardar el nombre de usuario, no la contraseña. Pongamos claro por cierto. que no tiene que almacenar la contraseña en el cliente para iniciar sesión. Puede almacenar un hash aleatorio que corresponde a un hash en el servidor.

— Luc Franken

12

Una forma es:

Cuando el usuario inicia sesión, guarde una ID de sesión en una cookie en la computadora del cliente (no el nombre de usuario o la contraseña).
Ate la sesión a la dirección IP, por lo que una ID de sesión individual solo funciona con la computadora en la que se inició.

Según el marco que esté utilizando para desarrollar su sitio, este comportamiento puede estar disponible como una característica incorporada.

Tenga en cuenta que, dado que el protocolo HTTP no tiene estado de todos modos, en realidad no existe una diferencia funcional entre mantener a alguien conectado durante una sola sesión de uso del sitio web e "inicio de sesión automático" la próxima vez que use el sitio; es solo una cuestión de cuánto tiempo permite antes de que expire la sesión.

Actualización: también, use HTTPS para mayor seguridad, obviamente.

Actualización 2: Tenga en cuenta que este enfoque tiene limitaciones, ya que no funciona bien para los usuarios que cambian mucho su dirección IP. Sin embargo, proporciona un mayor nivel de seguridad y puede ser útil en algunas situaciones.

1

Sin embargo, vincularlo a una dirección IP no ayuda mucho porque alguien podría tener una computadora que está detrás del mismo firewall que usted.

— Jay Simon

2

@ JaySimon, no diría "no ayuda mucho". La cantidad de computadoras detrás del mismo firewall que usted es mucho menor que la cantidad de computadoras en el mundo. Se trata de limitar su exposición potencial al ataque, y esto lo limita en gran medida. Este es un enfoque estándar, y realmente no creo que haya mucho que pueda hacer más allá. Si alguien tiene la misma dirección IP que el usuario y logra obtener una ID de sesión, esa persona será indistinguible del usuario desde la perspectiva del servidor. Si tiene algún tipo de inicio de sesión en su sitio, está expuesto a dicho ataque.

3

¿Crees que este enfoque será molesto para los usuarios de teléfonos móviles cuya dirección IP puede cambiar con frecuencia?

— Jay Simon

@ JaySimon, si sucediera dentro de una sesión, el usuario lo experimentaría como un cierre de sesión repentino, lo que sin duda sería molesto. Sin embargo, no sé con qué frecuencia cambian realmente (una búsqueda rápida en Google no revela una respuesta definitiva). No me preocuparía demasiado a menos que la IP cambiara mientras la usaban.

Restringir la sesión a la IP no es realmente realista como se dijo. Los usuarios cambian de ubicación con frecuencia. Con teléfonos móviles pero también con computadoras portátiles; por ejemplo trabajo flexible. Lo mejor que puede hacer es que algunas comprobaciones de GeoIP se combinen con el tiempo para recorrer esa distancia; como lo hace Gmail.

— Lode

5

Amazon (y muchos otros) usan un enfoque híbrido. Proporcionan inicio de sesión automático para navegar, agregar artículos al carrito y realizar pedidos utilizando combinaciones de direcciones de envío / crédito que ha utilizado anteriormente. Sin embargo, requieren que ingrese su contraseña para muchas acciones, como agregar tarjetas de crédito, agregar / cambiar direcciones de envío, actualizar contraseñas, ver pedidos anteriores (opcionalmente para el usuario) y muchas otras configuraciones de cuenta.

Entonces, sí, las personas que obtienen acceso a su computadora podrían secuestrar su sesión, ¡pero aún así obtienen lo que ordenan! (Más importante aún, el incentivo para secuestrar una sesión es bastante negado). Pero si alguien tiene acceso a mi computadora, tengo mayores problemas que las personas que roban las sesiones promedio del sitio.

Si tiene partes de su aplicación que no necesitan tanta seguridad, puede elegir un modelo híbrido donde almacene una ID de sesión (hash o lo que sea que desee) para iniciar sesión automáticamente en los usuarios de las partes de baja seguridad del sitio , pero pídales que ingresen la contraseña cuando ingresen a áreas de mayor seguridad y eliminen el token de alta seguridad cuando finalice la sesión.

Por supuesto, si este es un sitio de nivel bancario, entonces el inicio de sesión automático no es una opción. Nuevamente, los sitios que usan este tipo de seguridad asumen el valor de los datos que están protegiendo y la conveniencia adicional para el usuario sopesar el riesgo potencial de una sesión secuestrada. Si cree que ese no es el caso de su aplicación, no implemente los inicios de sesión automáticos. Debe acceder a qué nivel de seguridad / usabilidad son apropiados para su caso de uso.

— Eric G
fuente

2

En realidad no es tan difícil. Primero almacene una cookie con este formato:

userID.token

Puede usar un hash sha1 para el token. Luego, en su ID de usuario de la tienda de la base de datos remember_me_tokens, un hash bcrypt del token y la hora en que se generó el token.

Luego, cuando alguien visite su sitio, verifique si la cookie está configurada. Si la cookie está configurada, vea si hay una fila válida en la base de datos en los últimos 7 días, por ejemplo. Si hay una fila válida en la base de datos para la cookie, configure la sesión para indicar que el usuario ha iniciado sesión y también elimine la fila coincidente de cookie / base de datos y genere una nueva fila de cookie / token / base de datos.

Si cierran sesión, elimine la cookie.

Ejecute un trabajo cron para podar remember_me_tokens que tengan más de 7 días.

— Ryan
fuente

¿Qué impide que alguien copie esta clave y la pegue en su máquina y obtenga acceso a la cuenta sin el nombre de usuario o contraseña?

— Jay Simon

¿Cómo vas a obtener la llave? se almacena localmente en la computadora de alguien.

— Ryan

caminas hacia la computadora y abres el archivo donde está almacenado :)

— Jay Simon

2

@JaySimon Este mismo argumento puede hacerse para alguien que inicia sesión y se aleja durante 5 minutos sin bloquear su computadora, o hace clic en Recordarme y alguien salta la contraseña de su cuenta. Si puede aceptar esta posible situación de seguridad, entonces la conveniencia de esto es agradable, pero es por eso que no ve una función Recordarme en la lista CIA NOC :) El servidor debe darle algún tipo de token que el cliente debe almacenar en el sistema de archivos. Sin embargo, ya no está en tus manos desde la perspectiva del servidor.

— maple_shaft

@maple_shaft ¿por qué alguien se sorprendió de que pudieras hacer eso en Dropbox entonces? (Lo vinculé en mi pregunta.)

— Jay Simon

0

Solo puede hacerlo si confía en el dispositivo donde lo almacena. Depende del usuario (si no puede influir en el dispositivo) qué tan seguro es. Simplemente está fuera de tus manos.

Como se indica en los comentarios:

Se trata de lo que confías. Si no confía en la máquina, guarde la ID, entonces ese es su problema. Si confías en el llavero, esa es la máxima seguridad que obtendrás. Por supuesto, podría agregar un poco de seguridad personalizada, como detectar hardware del dispositivo o algo así, pero todo es falso, por lo que al final no puede saberlo. Está fuera de tu control.

— Luc Franken
fuente