Quanto è sicuro un demone Python Python per l'archiviazione di una password?

Question

Quanto è sicuro un demone Python Python per l'archiviazione di una password?

#1 da (1 voti)
#2 da (1 voti)

4

Sto usando il pacchetto Pyro per creare un demone che, all'avvio, richiederà una password, e quindi il daemon lo memorizzerà finché è in esecuzione. Altri script eseguiranno quindi una connessione Pyro a questo demone ed eseguiranno i metodi dal demone, nessuno dei quali rivela o ha accesso alla password:

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.

Vorrei ricevere consigli su quanto è sicuro e quali misure posso adottare per aumentare la sicurezza. Ad esempio, so che questo non è al 100% infallibile --- se qualcuno fosse in grado di scaricare la memoria, la password sarebbe probabilmente accessibile in quel modo. È uno sfortunato con cui sono disposto a vivere. Cos'altro?

Il modello "memorizzazione-password-in-memoria-tramite-demone" non è qualcosa da cui possa deviare. Questo approccio è stato deciso dal team nel suo insieme (al contrario di mettere la password in un file di testo di sola lettura root, per esempio). Quindi è meno una questione di "quali alternative ho", e più che altro, "quali strumenti posso utilizzare per svolgere questa particolare attività con il codice più semplice e facile da gestire senza sacrificare troppa sicurezza?"

python memory passwords password-management

posta CptSupermrkt 13.02.2014 - 05:20

fonte

2 risposte

Leggi altre domande sui tag python memory passwords password-management

Come condividere il token CSRF all'applicazione client? L'onestà del server può essere controllata dai peer remoti senza che i peer abbiano il controllo esclusivo (o alcuno) del server?

score 1 · Answer 1

Non ho familiarità con Pyro in particolare, ma questo modello è simile a molte altre impostazioni comuni.

Come hai detto, il demone sta memorizzando la password in memoria, quindi qualsiasi tipo di dump della memoria può recuperarlo.

Se un utente ha accesso locale alla macchina, potrebbe essere in grado di attaccare la voce della password iniziale. I keylogger sono lo strumento più ovvio qui; in scenari non-getpass, si potrebbe anche trapelare attraverso cose come la lettura della cronologia di bash (se si trovava nella riga di comando) o l'elenco dei processi (se si trovava nell'ambiente).

Un utente malintenzionato potrebbe sfruttare i difetti del demone per scrivere un programma che si connette ad esso e ottiene il ritorno della password.

A volte non importa nemmeno se hanno accesso alla password, a patto che siano autenticati. Potrebbero essere in grado di ingannare l'applicazione (tramite la connessione diretta al daemon o un attacco più remoto tramite attacchi di tipo SQL injection) per eseguire il codice di attacco con i privilegi del demone.

The "storing-password-in-memory-via-daemon" pattern is not something I can deviate from. This approach was decided on by the team as a whole (as opposed to putting the password in a root read-only text file for example). So it's less a matter of, "what alternatives do I have," and more a matter of, "what tools can I use to accomplish this particular task with the simplest and easiest to maintain code without sacrificing too much security?"

Questa sembra un'implementazione ragionevole del modello scelto.

score 1 · Answer 2

Come accennato, questo è un modello abbastanza comune. Le implementazioni di questi modelli di solito sono chiamate agenti chiave (ad esempio agente ssh, agente gpg). Suggerisco di guardare il loro design per avere qualche idea su come implementare il tuo. Meglio ancora, se puoi, passa ad assimmetrico auth / crypto invece di password e usa agenti preesistenti invece di scrivere il tuo agente. Sebbene la creazione di un agente di base e di lavoro non sia troppo difficile, la creazione di una soluzione sicura richiede molta cura (ad esempio impedire che le chiavi vengano scritte in swap, ibernazione / sospensione, limitazione dell'accesso al socket dell'agent).