¿Qué tan seguro es un demonio Python Pyro para almacenar una contraseña?

Question

¿Qué tan seguro es un demonio Python Pyro para almacenar una contraseña?

#1 de Xiong Chiamiov (1 votos)
#2 de Lie Ryan (1 votos)

4

Estoy utilizando el paquete Pyro para crear un demonio que, al iniciarse, solicitará una contraseña, y luego el demonio almacenará esa contraseña mientras se ejecute. Luego, otros scripts realizarán una conexión Pyro con este daemon y ejecutarán métodos desde el daemon, ninguno de los cuales revela o tiene acceso a la contraseña:

my_daemon.py :

import getpass
import Pyro.core

password = getpass.getpass()

class TestDaemon(Pyro.core.ObjBase):
   def __init__(self):
      Pyro.core.ObjBase.__init__(self)
   def do_some_stuff(self):
      return "I am a method which would do some stuff, utilizing password \"{0}\" which is only accessible from this daemon.".format(password)

Pyro.core.initServer()
daemon=Pyro.core.Daemon()
uri=daemon.connect(TestDaemon(), "TestDaemon")
daemon.requestLoop()

driver.py :

import Pyro.core
my_daemon = Pyro.core.getProxyForURI("PYROLOC://localhost:7766/TestDaemon")
print my_daemon.do_some_stuff()
# note: the password variable in the daemon is inaccessible from here.

Me gustaría recibir consejos sobre qué tan seguro es esto y qué pasos puedo tomar para aumentar la seguridad. Sé, por ejemplo, que esto no es 100% seguro, si alguien pudiera descargar la memoria, la contraseña probablemente sería accesible de esa manera. Ese es un desafortunado con el que estoy dispuesto a vivir. ¿Qué más?

El patrón de "almacenamiento-contraseña-en-memoria-vía-demonio" no es algo de lo que pueda desviarme. Este enfoque fue decidido por el equipo en su conjunto (en lugar de poner la contraseña en un archivo de texto de solo lectura de raíz, por ejemplo). Entonces, no es una cuestión de "qué alternativas tengo", y más bien es una cuestión de "¿qué herramientas puedo usar para realizar esta tarea en particular de la forma más sencilla y fácil de mantener el código sin sacrificar demasiada seguridad?"

passwords password-management python memory

pregunta CptSupermrkt 13.02.2014 - 05:20

fuente

2 respuestas

Lea otras preguntas en las etiquetas passwords password-management python memory

Guía para el desafío de restablecimiento de contraseña "basado en imágenes" ¿Existe una ventaja de seguridad al requerir una identificación de usuario en lugar de solo / me en una solicitud de API?

score 1 · Answer 1

No estoy familiarizado con Pyro específicamente, pero este patrón es similar a muchas otras configuraciones comunes.

Como has mencionado, el demonio está almacenando la contraseña en la memoria, por lo que cualquier volcado de memoria puede recuperarla.

Si un usuario tiene acceso local a la máquina, es posible que pueda atacar la entrada de contraseña inicial. Los keyloggers son la herramienta más obvia aquí; en escenarios que no son getpass, también puede filtrarlo a través de elementos como leer el historial de bash (si estaba en la línea de comandos) o procesar listas (si estaba en el entorno).

Un atacante puede aprovechar las fallas en el daemon para escribir un programa que se conecta a él y le permite devolver la contraseña.

A veces, ni siquiera importa si tienen acceso a la contraseña, siempre que estén autenticados. Es posible que puedan engañar a su aplicación (ya sea a través de la conexión directa con el daemon, o un ataque más remoto mediante ataques tipo inyección de SQL) para ejecutar el código de ataque con los privilegios del daemon.

El patrón de "almacenamiento-contraseña-en-memoria-vía-demonio" no es algo de lo que pueda desviarme. Este enfoque fue decidido por el equipo en su conjunto (en lugar de poner la contraseña en un archivo de texto de solo lectura de raíz, por ejemplo). Entonces, no es una cuestión de "qué alternativas tengo", y más bien es una cuestión de "¿qué herramientas puedo usar para realizar esta tarea en particular de la forma más sencilla y fácil de mantener el código sin sacrificar demasiada seguridad?"

Esto parece una implementación razonable del patrón elegido.

score 1 · Answer 2

Como se mencionó, este es un patrón bastante común. Las implementaciones de estos patrones generalmente se llaman agentes clave (por ejemplo, agente ssh, agente gpg). Sugiero mirar su diseño para obtener algunas ideas sobre cómo implementar el suyo. Mejor aún, si puede, cambie a auth / crypto asimétrico en lugar de contraseña y use agentes preexistentes en lugar de escribir su propio agente. Si bien la creación de un agente de trabajo básico no es demasiado difícil, crear un seguro implica tener mucho cuidado (por ejemplo, evitar que las claves se escriban para intercambiar, hibernar / suspender, restringir el acceso al zócalo del agente).