La forma ideal de almacenar contraseñas no rotas

8

Estoy tratando con un proveedor externo que claramente no comprende la seguridad: para acceder a su API desde mi back-end, tengo que proporcionar el ID / usuario / contraseña del usuario final para el servicio de terceros con cada lote de solicitudes .

Estoy luchando con ellos para al menos implementar algún tipo de autenticación basada en token revocable, pero mientras tanto tengo que lidiar con esto (al menos usan HTTPS ... sheesh).

Tengo que autenticarme con bastante regularidad para sincronizar los datos, y la sincronización debe realizarse sin la intervención del usuario final, por lo que básicamente significa que el BE debe almacenar las credenciales en un formato reversible. No soy lo suficientemente ingenuo como para almacenarlo en texto plano, pero incluso si lo cifro en la base de datos, la clave no estará muy lejos de la cerradura, por así decirlo.

Si no tuvieran almacenada una tonelada métrica de datos confidenciales, estaría menos preocupado, pero definitivamente es un dato que vale la pena asegurar. ¿Algún consejo?

Notas:

  • Las contraseñas se almacenarían en una base de datos distribuida. La base de datos en sí es razonablemente segura. La única posibilidad real de una violación sería una filtración de las credenciales de uno de los desarrolladores para acceder directamente a los datos, o un contratiempo de programación serio .
  • La API del proveedor no permite cambiar la contraseña mediante programación, por lo que la rotación de contraseñas no es una opción.

El acceso al código fuente del back-end se puede bloquear bastante bien. ¿Sería razonable almacenar una clave privada en la fuente y llamarla un día?

    
pregunta jdiaz5513 30.08.2013 - 16:10
fuente

2 respuestas

5

Lo mejor que puedes esperar de manera realista es usar las funciones que el sistema operativo local ofrece para almacenar "secretos". Esto significa DPAPI en Windows, Llavero en MacOS X ... use esto para almacenar la contraseña del usuario o alguna clave de descifrado para un archivo cifrado que contenga la contraseña del usuario. Las funciones de nivel de sistema operativo pueden tener un acceso más directo al hardware que lo que puede hacer a nivel de aplicación y, como tal, ofrecer una protección posiblemente más fuerte (menos débil) contra los atacantes. Además, no se le puede culpar por haber usado el método "recomendado por el sistema operativo" para almacenar secretos.

Si la máquina cliente es robada por completo, aún debe asumir que el atacante podrá recuperar la contraseña del usuario. Las posibles mitigaciones incluyen el uso de una función de bloqueo automático en la máquina cliente junto con el cifrado del disco duro (pero esto está fuera de su alcance como escritor de aplicaciones, y al usuario humano no le gusta la idea). El bloqueo automático significa que al atacante le resultará difícil (no imposible, pero difícil) meterse con la máquina cuando aún está encendida, y el cifrado del disco duro significa que reiniciar la máquina bloquea al atacante de forma permanente de los secretos almacenados (el cifrado del disco la contraseña debe ingresarse cada vez que la máquina arranca).

    
respondido por el Thomas Pornin 30.08.2013 - 16:30
fuente
0

Esto no es inaudito cuando se trata con API de terceros. Incluso si le brindan un "token" en lugar de una contraseña, esos tokens le dan acceso a la cuenta (aunque en muchos casos están limitados de alguna manera), por lo que deben protegerse con cuidado. Soluciones que conozco:

  1. Almacene el nombre de usuario / contraseña en el código fuente. Ya que esto es tan fácil, la gente lo hace todo el tiempo. Sin embargo, me pone nervioso: lo ideal es que su código esté en control de código fuente, por lo que cualquier persona que tenga acceso a él tendrá las credenciales.

  2. Guárdelo en un archivo de configuración (idealmente con permisos limitados para que no pueda ser leído por usuarios no autenticados, etc.). Personalmente, encuentro que esto es un poco mejor que el # 1, ya que idealmente debería haber muy pocas copias de esto.

  3. Guárdelo en la RAM y obtenga la contraseña del usuario o de la red cuando se inicie o sea necesaria. Este es probablemente el más seguro, pero puede ser un inconveniente para el usuario o requiere un servicio de "credenciales cifradas".

Creo que para la mayoría de las aplicaciones, la solución del archivo de configuración (# 2) es razonable, suponiendo que genere una contraseña aleatoria para esta cuenta que no se reutilizará en ningún otro lugar, y el sistema en sí es bastante seguro. Para cosas realmente importantes, es posible que desee ir por el camino de solo almacenar las credenciales en la memoria.

Recientemente utilicé ese enfoque para darle a un servidor una clave de cifrado para datos críticos en una base de datos. Significa que si el servidor se reinicia, alguien debe escribir manualmente una frase de contraseña, pero también significa que si alguien se marcha con los discos, no obtiene los datos.

    
respondido por el Evan Jones 30.08.2013 - 20:45
fuente

Lea otras preguntas en las etiquetas