¿Es seguro permitir a los usuarios el inicio de sesión múltiple en diferentes navegadores y computadoras?

Hay una buena razón para evitar las conexiones concurrentes, si sus usuarios no las necesitan.

Una buena regla general es no permitir más funcionalidad que la que se necesita. Si sus usuarios nunca van a conectarse a más de una sesión simultánea, no permitiría reducir el riesgo de ataque (ya que un atacante no podría realizar su ataque mientras el usuario estaba conectado).

Sin embargo, si sus usuarios esperan usar varias sesiones, entonces tendrá que tener esta funcionalidad.

Realmente, esta pregunta se reduce a un problema de funcionalidad: Google sabe que sus usuarios pueden necesitar conectarse desde múltiples máquinas / ubicaciones / navegadores al mismo tiempo, por lo que solo notifican otras sesiones, en lugar de prohibirlas.

Creo que todas las respuestas dadas hasta ahora son todas válidas. Sin embargo no estoy seguro de estar completamente de acuerdo. Tomemos este sitio por ejemplo. Puedo tener varias sesiones abiertas e iniciadas sesión en stackexchange.com, ¿eso hace que security.stackexchange.com sea menos seguro? Creo que los méritos de eso son discutibles, y hay argumentos y puntos en contra en el argumento. Aunque diría que cualquier aumento en el riesgo de seguridad por permitirlo es insignificante.

Creo que el problema de los inicios de sesión múltiples que dependen del escenario es menos una cuestión de seguridad y más una cuestión de proceso. Puede tener sentido no permitir inicios de sesión múltiples debido al proceso de negocios, por ejemplo, la licencia. Pero en otros escenarios puede tener sentido, por ejemplo, aumentar la usabilidad. Depende de usted como arquitecto decidir si el aumento en el riesgo merece algún beneficio percibido, o un aumento en el trabajo para deshabilitar los inicios de sesión múltiples.

No creo que permitir que múltiples usuarios se conecten es vulnerable a ataques. Si Gmail lo permite, estoy seguro de que pensaron en los riesgos potenciales;)

Ahora, eso no significa que su aplicación no sea vulnerable, sino que se basará más en cómo desarrolló el proceso de inicio de sesión (https, base de datos con contraseña de hash, etc.).

Ya que mencionó que ha asegurado su aplicación como se indica en esa publicación , ha reducido considerablemente el riesgo (no puedo decir que sea 100% seguro, nada lo es).

Ahora, puede agregar la misma función que Google Mail: lista de todas las sesiones conectadas actuales para el usuario. Al hacerlo, si una cuenta de usuario es hackeada y se accede a ella en otro lugar, será posible verla, la IP detrás de ella, etc.

No será más seguro, pero proporcionará un poco de alivio a sus usuarios.

Creo que el problema y la preocupación realmente están definidos por los datos y los sistemas en cuestión. Si cada inicio de sesión, permite la mutación (cambio) de los datos compartidos, o el cambio en los sistemas compartidos, entonces tener múltiples inicios de sesión por parte del mismo usuario es un problema.

En el caso de Gmail, los datos en cuestión son individuales y no se comparten, por lo que nunca es el caso. Si cambio mi gmail en un inicio de sesión, solo me estoy disparando en el pie.

También desde un punto de vista de seguridad, existen algunas inquietudes que plantearía / consideraría:

1. Cada vez que permite múltiples inicios de sesión concurrentes, esencialmente está diciendo que tiene conexiones no seguras a su sistema. Si la computadora en la que se está ejecutando el sistema no está bien protegida, entonces el "portal" está abierto y es gratuito para alguien que no es el usuario adecuado que abusa del inicio de sesión, por lo que ha perdido la trazabilidad y el repudio de su sistema.

2. Por supuesto, cualquier página activa (a menos que sea HTML puro) representará un "portal" de posibles explotaciones que, si un agresor tiene acceso al ataque, puede explotar para una mayor escalada más allá de la autorización del usuario registrado. O incluso peor, puede crear un portal para atacar los sistemas en los que se alojan la aplicación y sus datos y subvertir todos los controles y obtener acceso completo a las "joyas de la corona", por así decirlo.

3. Finalmente, nunca creas tu propia BS, no has asegurado tu aplicación. Ha hecho todo lo posible para asegurar su aplicación con lo mejor de su conocimiento en ese momento, de lo contrario, no habría ataques de 0 días. Por eso, nunca crea que su aplicación está "asegurada" y, por lo tanto, puede hacer algo que parezca nominal como lo está proponiendo. No se pretende ofender aquí, pero es la verdad. Siempre sea paranoico acerca de la seguridad.