¿Cuáles son todos los problemas con el almacenamiento de una contraseña de texto simple?

Sé que esto no responde directamente a tu pregunta, pero otro enfoque sería hacer que la aplicación se autentique al servicio para configurar un canal confiable entre los dos. La aplicación podría simplemente pasar las afirmaciones de identidad en nombre del usuario, y no se necesitarían contraseñas por usuario.

La suposición aquí es que el servicio está feliz de confiar en la aplicación.

Me dirijo a esto:

  

Si la contraseña en cuestión se genera aleatoriamente y solo la utiliza el servidor para autenticarse en nombre del usuario para un servicio (un intento de "inicio de sesión único"), [el riesgo de revelar una contraseña que el usuario pueda estar usando para otras cuentas] es negado

Esto es solo parcialmente cierto. Si solo está almacenando una contraseña generada ALEATORIAMENTE que es utilizada solo por su sistema, entonces solo reduce el riesgo. La razón por la que no se niega es porque si alguna vez revela esta contraseña generada aleatoriamente a su usuario, MIGHT terminará usando esto para sus cuentas reales (esto sucede más a menudo de lo que piensa)

En cuanto a lo siguiente:

  

Un atacante ahora puede iniciar sesión como usuario en su sitio (aunque, ¿no podrían simplemente cambiar el hash en la base de datos para que sea una nueva contraseña en ese momento?)

Use una sal. Incluso puede almacenar la sal en la base de datos y manipularla programáticamente dentro de su código cuando calcula el hash (puede almacenar la sal X , pero en realidad usa una manipulación de X cuando calcula la hash). De esta manera, incluso si alguien puede modificar los valores almacenados en su base de datos, no podrán iniciar sesión a menos que sepan cómo usó el Salt que almacenó + contraseña para calcular su hash. Dado que este es el inicio de sesión único, piense en lo malo que sería si alguien pudiera iniciar sesión con una cuenta privilegiada para su servicio. ¿Qué puertas podrían abrir?

También hay un caso en el que el atacante solo puede leer su base de datos. Si tiene una vulnerabilidad en una consulta de selección, creo que lo único que puede hacer el atacante es leer los datos de su base de datos, y obviamente es mucho mejor si las contraseñas están ocultas.

Para responder a tu pregunta, aquí están todas las cosas malas acerca de las contraseñas de texto claro que se me ocurren de la cabeza:

1. Contraseñas fáciles de robar por empleados deshonestos
2. Fácilmente (y sin querer) navegando por los hombros y memorizado.
3. Puede terminar apareciendo en texto claro en volcados de núcleo, registros u otros lugares no deseados.
4. Los piratas informáticos pueden obtener fácilmente las contraseñas si pueden obtener una copia de su base de datos. Esto no siempre significa que su servidor de base de datos deba estar comprometido, por cierto (es decir, podrían robar una copia de seguridad o el ordenador portátil de desarrollo de alguien).
5. Puede revelar información confidencial adicional (por ejemplo, si un usuario utiliza una variante de su cumpleaños como su contraseña)
6. Pérdida de reputación inmediata si ocurre un incidente o su arquitectura se hace pública alguna vez.
7. Falla la mayoría de los niveles de cumplimiento para HIPAA, PCI-DSS, etc. Incluso si es solo para hablar con Jabber, ya que probablemente un equipo criminal podría hacerse pasar por un usuario final y usar un ataque de ingeniería social.
8. Dependiendo de su jurisdicción, puede indemnizar a los piratas informáticos contra ciertos cargos legales, por ejemplo, puede ser ilegal descifrar la contraseña pero no leer una en texto claro.
9. Otros programadores se reirán de ti.
10. La seguridad cibernética es tan fuerte como su enlace más débil.

Para responder a su pregunta real , el esquema típico para este tipo de cosas sería el siguiente:

1. El usuario final se autentica con su sitio web
2. El usuario final indica que desea utilizar Jabber (por ejemplo, hace clic en un enlace)
3. Su servidor se comunica con Jabber utilizando credenciales que se han generado aleatoriamente para este usuario específico
4. Jabber autentica su servidor a través de una lista blanca de IP, certificados de clientes u otros medios comunes.
5. Jabber autentica las credenciales y crea una sesión para el usuario final.
6. Jabber devuelve la clave de sesión a su servidor.
7. Su servidor devuelve la clave de sesión al navegador del usuario
8. El navegador ahora puede usar Jabber.

Bajo este esquema, las credenciales mencionadas en el paso 3 no están modificadas, ya que deben ser recuperables. Esto es inevitable, y no es infrecuente; en situaciones en las que está involucrado el cumplimiento (por ejemplo, HIPAA en su caso), las credenciales se pueden cifrar en su lugar, utilizando un secreto maestro (AES128 es la opción predeterminada) guardada en una parte segura de su sistema (por ejemplo, el almacén de certificados de Windows o el uso de Crypto API ). El acceso a los secretos se puede hacer cumplir a través de los permisos de la cuenta de servicio; solo el microservicio específico que habla con Jabber debería poder acceder a ellos, y solo debe exponer los ID de sesión que se hayan creado, nunca las credenciales en sí mismas.

Tenga en cuenta también que debe pensar en esquemas para hacer rodar el material criptográfico cada pocos meses, o inmediatamente a pedido si su sistema alguna vez se ve comprometido.

Hay dos riesgos principales con el almacenamiento de contraseñas de texto simple.

1. Muchas personas reutilizan sus contraseñas y usted las está poniendo en riesgo si hay una violación de seguridad de su sitio.

2. Los administradores del sistema, los operadores de copia de seguridad y otros pueden ahora tener acceso a las contraseñas de los usuarios. Esta es una mala práctica.

Sí, tienes razón en que si un atacante compromete tu sistema y obtiene acceso total a tu base de datos, podrían modificar la contraseña con hash incluso si hash las contraseñas. Hashing no impide la modificación. En principio, si un atacante logra obtener acceso de solo lectura a su base de datos (por ejemplo, una copia de seguridad se roba del maletero de su automóvil), entonces el hashing es más seguro: si almacena contraseñas de texto simple, el ladrón tiene todas sus contraseñas, mientras que con el hash, el ladrón no obtiene inmediatamente todas tus contraseñas.

También sugiero leer las otras preguntas en la etiqueta contraseñas .

Iba a hacer esto como un comentario, pero cuando fui a escribirlo, pensé que era más que una respuesta. Claramente, esta función de servicio Jabber debe estar 100% separada de la información de salud. Debe cumplir con las leyes TODAS sobre el almacenamiento de información de salud.

Lo que me lleva al siguiente pensamiento: ¿Jabber no soporta OAuth? El usuario en cuestión debe conocer en algún momento su nombre de usuario y contraseña para autenticarse con el servidor Jabber de terceros.

Por lo tanto, hay dos formas de manejar el acceso a la cuenta "jabber". Si no desea que el usuario proporcione los detalles de autenticación, entonces realmente solo tiene una opción, cree la cuenta para el usuario y maneje la autenticación usted mismo.

Puede hacer esto creando el nombre de usuario y la contraseña para el usuario. Puede usar un sistema de autenticación como OAuth donde el cliente y el servidor intercambian información. OAuth le permite al usuario solicitar el token, luego el servidor otorga el token y esto le permite al cliente acceder a los contenidos. Esta aprobación se puede quitar sin problemas en cualquier momento.

Esto requiere que usted sea el "usuario" y proporcione la información al servidor para que el cliente pueda aprobar el acceso del cliente al contenido. Por lo tanto, la otra solución implicaría que el usuario proporcione la información una vez y utilice un mecánico similar, obteniendo la aprobación hasta que se revoque la aprobación.

Sinceramente, no entiendo la preocupación. El acceso al servicio Jabber, si está separado de la información de salud, no conduce a una filtración de información de identificación personal (PII) e información médica.