¿Qué sucede si el cliente necesita la capacidad de recuperar contraseñas?

Actualmente heredé una aplicación en el trabajo y para mi consternación, me di cuenta de que las contraseñas de los usuarios almacenadas en la base de datos están encriptadas utilizando una función de encriptación interna, que también incluye la capacidad de desencriptar.

Entonces, todo lo que alguien realmente necesita hacer es copiar la tabla de usuarios y copiar el ensamblado de cifrado (cualquier persona con acceso a la producción de la base de datos) y luego tendrían acceso a 100,000 direcciones de correo electrónico y posibles contraseñas para ellos.

Estoy tratando de explicarle al negocio por qué esto no es una buena idea, pero los conceptos de seguridad parecen pasar por alto ya que no tienen una mentalidad técnica (es para el gobierno). Además, en realidad hay una funcionalidad existente dentro de la aplicación para que los usuarios administradores recuperen las contraseñas de los usuarios con el fin de iniciar sesión como ellos y hacer cosas (lo que han dicho, requieren).

Entonces no entienden las implicaciones de seguridad. Y para implementar una política de seguridad más sólida (contraseñas hash para que no se puedan recuperar fácilmente), tengo que eliminar la funcionalidad existente para ellos.

¿Qué tengo que hacer? No construí el sistema de contraseña en primer lugar, por lo que no es como si me pudieran culpar si algo sale mal. Por otro lado, no me siento bien al respecto y tampoco quiero tener acceso a 100.000 posibles inicios de sesión por correo electrónico.

Implemente la funcionalidad que necesitan de forma segura. Los administradores que inician sesión como otro usuario pueden implementarse sin que sepan la contraseña del usuario. Pueden iniciar sesión como ellos mismos y luego tener alguna función de 'cambio de identidad' disponible.

Asegurar una base de datos de contraseñas no es una preocupación comercial, es una preocupación técnica. No hacerlo es un error. Si la empresa piensa que la seguridad es una compensación funcional, la seguridad perderá. No debes darles ninguna razón para pensarlo de esta manera.

Debe convencerlos de que realmente no necesitan ser responsables civilmente en caso de que su servidor sea allanado. Tampoco necesitan la reacción de una base de usuarios informada que se da cuenta de que están siendo negligentes.

A veces hay casos claros en que una parte está equivocada y la otra tiene razón. Éste es uno de esos momentos.

Mira lo que le acaba de pasar a Sony. Además, nuestro sitio fue pirateado recientemente, y una de las cosas que impidió que fuera un desastre no mitigado fue que utilizamos una función de hashing unidireccional (relativamente) buena (SHA512). Desde entonces hemos cambiado a bcrypt para evitar incluso ataques de fuerza bruta / diccionario (o al menos hacerlos insostenibles). Simplemente no encuentro nada más concienzudo.

Hecho: las personas usan la misma contraseña en muchos sitios

Su jefe probablemente no se dé cuenta de que las personas a menudo usan una sola contraseña (o un conjunto muy limitado de ellas) para todo tipo de servicios (incluidos los servicios bancarios o de Facebook y similares). Si los usuarios pueden cambiar su contraseña en su sistema, es muy probable que usen la misma contraseña que en otros lugares.

Si su jefe piensa que este acceso con contraseña no es un problema, también debe decirles este hecho y tal vez comenzarán a pensar de manera diferente. Incluso si su aplicación está detrás de la pared y no es de acceso público, puede representar una amenaza para la seguridad en otros servicios en línea. Los nombres de usuario (especialmente cuando son correos electrónicos) son bastante fáciles de adivinar. No puedo imaginar lo divertido que sería iniciar sesión en la cuenta de Facebook del jefe y poner algo en su muro.

Las contraseñas de los usuarios siempre deben tratarse como información confidencial / confidencial de primer nivel a la que solo tiene acceso un número limitado de personas. Es mejor evitar almacenar información tan volátil. E incluso cuando lo haga, se le debe otorgar acceso individual a esta información. Como obtener un documento confidencial de una caja fuerte altamente segura que solo se puede abrir con varias llaves. Entonces la gente sabe a quién se le ha otorgado acceso y cuándo.

Cómo implementar la delegación de cuenta

La delegación de cuentas en su solicitud debe hacerse de manera diferente.

1. Los administradores deben iniciar sesión como ellos mismos y luego
2. tampoco (ya que son usuarios privilegiados)
   • ingrese solo Nombre de usuario o
   • seleccione un determinado usuario de una lista para iniciar sesión como ellos

Definitivamente no debe hacerse iniciando sesión con la combinación de Nombre de usuario + Contraseña .

Es cierto que se debe desarrollar una nueva pantalla para permitir el inicio de sesión delegado, pero aún así.

¿Por qué es mejor el inicio de sesión delegado?

También podría proporcionar una funcionalidad adicional que dejaría en claro que el administrador ha realizado alguna acción en nombre de algún usuario (que no puede saber ahora porque los administradores actúan como dioses e inician sesión como quien sea y pueden estar haciendo cosas que pueden dañar) reputación real de los empleados).

Tienes que aceptar que la gente comete errores. Los administradores también son personas. Y si cometen un error en nombre de otra persona, intentarán culparlos. Estoy 100% seguro de eso. Esto hará que sea más seguro para los usuarios que no son administradores, por lo que su reputación en el mundo real no sufrirá errores de otras personas.

No mencionas lo que hace la aplicación. Si se trata de solicitudes de pasaportes, llenas de información de robo de identidad que deben protegerse, merece la máxima protección. Pero si es "dime los accidentes de tránsito en mi ruta a casa", ¿cuáles son las consecuencias de una violación de contraseña? Algunos sistemas que he escrito ni siquiera tienen contraseñas: solo ingrese su correo electrónico o su número de estudiante o algún otro identificador que las personas a menudo se conozcan, y los propietarios del sistema valoran la facilidad de uso y la imposibilidad de ser bloqueado sobre la posible violación de la privacidad si las personas se suplantan entre sí. No tengo ningún problema con eso tampoco. ¿Por qué necesito una contraseña para configurar mi horario de sesiones preferidas en una conferencia, por ejemplo?

Entonces, si me traían para una revisión de código y me lo planteaste, ahí es donde comenzaríamos. ¿Qué estás protegiendo? ¿Cuáles son las consecuencias negativas de que una persona logre iniciar sesión como otra persona? ¿Cuáles son las consecuencias negativas de la exposición de los datos almacenados de todos? Quizás son horribles. Los enumerarías por mí. Entonces, ¿cuáles son las consecuencias de que las personas no puedan hacer clic en "enviarme mi contraseña por correo electrónico" sino que tengan que hacer clic en "restablecer mi contraseña"? ¿Dejarían de usar el sitio? ¿Y qué hay del personal que inicia sesión como persona? ¿Eso es ahorrar tiempo, dinero, ventas perdidas o qué?

La parte final de la historia de costo / beneficio, y una de las que llega solo si hay una diferencia realmente grande entre los aspectos negativos a los que está expuesto ahora y los aspectos negativos que obtendrá cuando elimine la funcionalidad, es el costo para solucionarlo. ¿Gastaría un millón para ahorrarme la posibilidad de una exposición de mil dólares? No. ¿Qué pasa al revés? Depende de las probabilidades, supongo, pero mi primera respuesta sería sí.

pd: el gobierno canadiense comenzó a funcionar con un sitio para solicitar su pasaporte que tenía identificaciones en la URL: si editó la URL con una identificación diferente, vio la forma a medio completar de algún otro ciudadano al azar. Y tengo clientes que se registran como sus clientes con fines de servicio al cliente para la felicidad general, por lo que veo el lado bueno de esto, aunque no lo toleraría si los datos detrás de la contraseña fueran realmente importantes para los extraños.

Puede ser contra la ley y podría abrirlos para ser demandados. Si se retiene algún tipo de información personal sobre el usuario, o el sistema interactúa con otros sistemas como el usuario, es posible que necesite verificar si el sistema cumple con alguna de las leyes o leyes de privacidad estatales o federales. es decir. Sarbanes / Oxley, California OOPA, etc.

Además de los posibles problemas legales, también puede señalar que cualquier administrador podría en cualquier momento volcar la tabla completa en un dispositivo de datos portátil y salir con la capacidad de iniciar sesión como cualquier usuario y causar estragos, o vender los datos.

Incluso si asume que todos los administradores son confiables, también compromete una contraseña de administrador devastadora.

Tampoco necesita la contraseña de un usuario para realizar operaciones como ellos. Puede implementar una sudocaracterística similar.

Esto no puede ser un sistema del gobierno federal, ya que los requisitos de FIPS y FISMA prohibirían el cifrado reversible de contraseñas, y el departamento principal los abofetearía.

Y para implementar una política de seguridad más sólida (contraseñas hash para que no se puedan recuperar fácilmente), tengo que eliminar la funcionalidad existente para ellos.

Para mi empresa anterior, seguí luchando por la capacidad de enviar correos electrónicos de restablecimiento de contraseña para solucionar este problema. Y seguí siendo anulado. Al final, me cansé de palear caca contra la marea, así que me fui. Este también era un jefe de pelo puntiagudo que pensaba que las estúpidas preguntas que hacen algunos sitios web de bancos contaban como "autenticación de 2 factores". Discutir con él era como una caricatura de Dilbert (tenía la forma del PHB).

Además, en realidad hay una funcionalidad existente dentro de la aplicación para que los usuarios administradores recuperen las contraseñas de los usuarios con el fin de iniciar sesión como ellos y hacer cosas (lo que han dicho, requieren).

He visto esto implementado en una institución financiera. Las personas en el área de atención al cliente iniciarían sesión con sus propias credenciales y, si tuvieran los derechos para hacerlo, podrían pretender iniciar sesión como el cliente. Esto no los conectó como el cliente, simplemente suplantó al cliente . De esa forma, si el representante de servicio al cliente decidiera retirar dinero, no se mostraría como el cliente lo hace en los registros: mostraría al representante de servicio al cliente tratando de hacerlo (además de enviar una alerta para que lo despidan tan pronto como sea posible). el rentacop podría llegar a su piso).

Si se hace mal, haría que el personal de atención al cliente pueda hacer que parezca que el usuario final se involucró en alguna actividad que podría resultar en serias responsabilidades financieras o legales.

El último sitio web federal en el que trabajé recaudó 1/4 billones de dólares estadounidenses por año de los usuarios finales (de los cuales había alrededor de 400 usuarios), por lo que el registro tuvo que ser muy estricto y solo el usuario final autorizado podía tocar las páginas web donde informaron sobre las cosas por las que pagaron impuestos especiales.

Sony fue una de las compañías con la última violación de seguridad. No era solo la red PS3, también era su red de juegos MMORPG, con un total de más de 25,000,000 de nombres, direcciones, números de tarjetas de crédito, nombres de usuario y contraseñas. Puedes creer que no soy feliz en absoluto (¡quiero mi evercrack!).

Me refiero al Código de Ética de Ingeniería de Software en preocupaciones como esta. Mi interpretación, su primera prioridad es no socavar el interés público (no como una posibilidad de contraseña comprometida más como este ejemplo aquí donde una compañía modificó las computadoras portátiles Dell para que la compañía de alquiler pudiera espiar a sus inquilinos sin que ellos lo supieran). Después de eso, su responsabilidad es INFORMAR a su cliente sobre los riesgos potenciales y dejar que lo tengan en cuenta. Por supuesto, esa es la línea de base mínima. Tienes que usar tu propio juicio sobre si sientes que esto es aún más de lo que puedes soportar y permitir.

Por supuesto, cuando mencionas un proyecto del gobierno, si la información privada de los ciudadanos está en riesgo debido a estas prácticas, entonces está minando el interés público.

Puede imprimir la lista de correos electrónicos y la contraseña descifrada y ponerla en el escritorio de su jefe, con una gran advertencia en la portada: "Confidencial"

Haga que la fuente sea pequeña para no desperdiciar papel.

También podría mostrarles cómo bugzilla permite a los administradores hacerse pasar por personas sin usar su contraseña.

En primer lugar, estoy de acuerdo con las otras respuestas señalando que es mucho más seguro evitar esto, y solo almacenar hashes de contraseñas, no las contraseñas en sí mismas, o cualquier cosa que pueda transformarse de nuevo en una contraseña.

Sin embargo, hay momentos en que más o menos necesita permitir la recuperación. En el caso de las contraseñas, generalmente desea recuperar simplemente permitiendo que un administrador cambie la contraseña cuando sea necesario, en lugar de recuperar la contraseña existente.

Sin embargo, otra posibilidad es que permita que el usuario almacene datos en el servidor que están cifrados con su propia contraseña. En este caso, simplemente permitir que un administrador cambie la contraseña no es suficiente. La nueva contraseña no funcionará para descifrar los datos, y la mayoría de los usuarios considerarán inaceptable que todos sus datos cifrados se vuelvan inaccesibles cuando / si olvidan / pierden una contraseña. Para esta situación, existe una alternativa que es razonablemente segura y que aún permite la recuperación cuando realmente se necesita.

En lugar de utilizar la contraseña del usuario para cifrar los datos, crea una clave aleatoria para cifrar los datos en sí. Luego almacena esa clave, en un par de lugares: una vez encriptada con la contraseña del usuario, y en otro lugar encriptada con una contraseña de administrador. Luego, cuando (no realmente si) el usuario pierde su contraseña y ya no puede acceder a los datos directamente, puede usar la contraseña de administrador para descifrar la clave real y usarla para recuperar los datos y / o volver a cifrar la clave con La nueva contraseña del usuario.

Si no desea confiar completamente en un solo administrador, también puede administrarlo. Por ejemplo, puede decidir que 5 personas tendrán claves de administrador, y desea que al menos tres de ellas estén de acuerdo antes de que se pueda recuperar una clave. En este caso, cuando almacena la contraseña cifrada para fines administrativos, la almacena varias veces, una para cada grupo de tres de los cinco administradores (lo que no ocupa mucho espacio, ya que solo está almacenando varias claves , a ~ 256 bits cada uno, no copias múltiples de los datos). Cada una de esas copias se cifra sucesivamente con (los hashes de) cada una de las contraseñas de esos tres administradores.

Para descifrarlo, debe identificar a los tres administradores que ingresan sus contraseñas, y elegir la clave cifrada adecuada para ese conjunto de tres, luego descifrar usando cada una de las tres contraseñas para finalmente obtener la clave original. Luego puede usar eso para recuperar los datos en sí, o simplemente puede volver a cifrarlos con el (hash de) la nueva contraseña del usuario para que aún puedan acceder a sus datos.

Sin embargo, cuando hace esto, realmente necesita usar un algoritmo de encriptación estándar y (por preferencia fuerte) una implementación estándar, bien conocida y estudiada a fondo.

Esto me preocupa, dado que es para un proyecto gubernamental. Recuperar la contraseña de un usuario para realizar una acción con su ID hace que cualquier tipo de auditoría de seguridad sea una tontería. La única razón por la que puedo ver esto es para crear una pista de auditoría falsa.

Realmente no hay necesidad de usar cifrado reversible para contraseñas. Si alguna vez hay una razón legítima para falsificar una identificación de usuario, puede hacerlo:

• Almacenar el hash de contraseña actual
• Reemplazar con un valor conocido
• (Actividad de seguimiento de auditoría falsa, por ejemplo, transferir fondos a una cuenta en el extranjero)
• Reemplazar hash de contraseña original

Me sentiría incómodo con el último paso: quien haya sido suplantado en el sistema debería saber que ha sucedido. Quizás pueda persuadir al negocio diciendo "Es como si su banco me permitiera acceder a su cuenta sin su conocimiento, porque dije que realmente necesitaba".

Su creencia en un mejor sistema de contraseña no es el problema. Cree una solución para permitir que un administrador / soporte se haga pasar por una cuenta de usuario y proporcione su solución para las contraseñas. La seguridad a menudo sufre por conveniencia. Que sea conveniente y seguro.

Editar: Nunca, nunca, comprenderán completamente el problema de seguridad de la contraseña, pero sí entienden la pérdida de funcionalidad. Haga esta propuesta y vea si puede obtener la aprobación para realizar los cambios necesarios. Ni siquiera saben si les llevará una hora o un año. Es un cambio de características y no una reconstrucción completa.

Teniendo en cuenta los eventos actuales (la fuga de datos de Epsilon y la fuga de datos de Playstation Network), uno esperaría que los problemas fueran evidentemente obvios.

Sin embargo, a veces, como desarrollador, simplemente no puede afectar la política.

Haría todo lo posible para mostrar el potencial de escándalo y gasto, que debería ser fácil, una vez más considerando los eventos actuales. Pero si eso no tiene éxito, ¿qué puedes hacer realmente? No mucho. Renunciar en protesta, demostrar la vulnerabilidad para llamar la atención. Ninguno de los dos parece una gran opción.

Aconsejaría en contra de esto, pero si absolutamente debe tener la capacidad de descifrar las contraseñas, debe usar el cifrado de clave pública. De esa manera, puede cifrar todas las contraseñas con la clave pública. Puede verificar las contraseñas cifrando con la clave pública y comparando, y puede mantener la clave privada en otro lugar (no en la computadora de producción).

Por lo general, la razón para que un administrador vea la contraseña del usuario es en caso de que la pierda, puede dársela al usuario. Por lo que puedo decir, Windows tampoco permite que el Administrador vea la contraseña, entonces, ¿por qué debería su aplicación? Cualquier biblioteca de cifrado interna seguramente se romperá porque estoy seguro de que quien la escribió no funciona para la NSA.