Metodi per la memorizzazione di password in chiaro su un client

Come al solito con questo tipo di domande, iniziamo definendo un Modello di minacce . La Electronic Frontier Foundation ha un articolo chiamato Valutazione del modello di minaccia dove ti chiedono di meditare su tre domande ( mio in corsivo ):

1. What are you protecting? (The data, communications, and other things that could cause problems for you if misused)
2. Who are you protecting it from? (The people, organizations, and criminal actors who might seek access to that stuff)
3. How many resources can you invest in protecting it? (The money, time, and convenience you're willing to dispense with protecting those things)

Sembra:

1. Stai proteggendo A) i dati che sono già pubblici, almeno all'interno della tua organizzazione, e B) un nome utente / password per questo contenuto.
2. Lo stai proteggendo dagli hacker che entrano nel tuo server, che è sepolto in profondità nella rete locale, ma escludendo come una minaccia chiunque abbia accesso fisico all'ufficio (e presumibilmente anche l'accesso alla rete?). Quindi quali sono gli attori di minacce che stai effettivamente cercando di proteggere?
3. Sembra che tu sia disposto a investire qualche sforzo nella protezione del nome utente / password, ma non puoi avere un babysitter umano 24/7.

Come indicato nella domanda e nei commenti, il software ha bisogno di accedere al nome utente / password, quindi il meglio che puoi fare è crittografarlo su disco e richiedere a un essere umano di inserire la password di decrittazione di volta in volta. Esistono alcune opzioni su come eseguire questa operazione a seconda del modello di minaccia / del paranoico che si desidera essere:

1. Usa openssl (o altre crypto lib) nella tua app per leggere il file crittografato dal disco e chiedi a un umano la password di decodifica ogni volta che il raschietto lo richiede, quindi cancellalo dalla memoria (questo protegge dagli utenti malintenzionati che hanno compromesso il server su cui è in esecuzione).
2. Utilizza openssl come sopra, ma richiede solo una password di decrittazione all'avvio del processo.
3. Trova qualche trucco di Linux che lo protegga all'interno della home directory dell'utente (qualcosa di equivalente a API di protezione dei dati di Microsoft ).
4. Se si tratta di un server per utente singolo o se non si è preoccupati di trattare altri utenti come dannosi, abilitare la crittografia completa del disco sulla macchina in modo che richieda una password durante l'avvio. Questo protegge solo dal furto fisico del server, ma forse è appropriato per il tuo modello di minaccia?

Dovresti anche creare un account utente separato per il raschietto piuttosto che dargli le credenziali di un utente umano, questo A aiuta a controllare i registri per comportamento bizzarro causato dal raschiatore, B) protegge la password di quella persona da perdite, specialmente se riutilizzano quella password per altri account, C) ti consente di sospendere facilmente l'account di Scraper se sospetti compromessi.

La soluzione rapida e facile (ma sbagliata) è una password principale per crittografare i login e le password. Dovrai digitare questa password ogni volta che esegui lo script. Se non vuoi doverlo digitare ogni volta, puoi vedere questa domanda per altre opzioni.

Il modo corretto per farlo è andare all'amministratore del tuo sito interno e chiedere loro le credenziali di scraping web che ti danno tutti i diritti di accesso appropriati per racimolare ciò di cui hai bisogno. Non si dovrebbe mai avere accesso ai login e alle password degli altri. È pericoloso per l'azienda e una responsabilità per te stesso se succede qualcosa di brutto. Sfortunatamente, questo potrebbe non essere un'opzione in quanto richiede la collaborazione di qualcun altro.

My question: How can I make the stored plaintext passwords on the client as low a risk as possible, given that it is impossible to avoid altogether?

Se hai davvero bisogno di salvarlo su disco, potresti spiegare qual è il motivo? Questo potrebbe rendere più facile dare una risposta precisa. Potrei immaginare che lo memorizzi non criptato perché lo hai codificato nella sceneggiatura? E lo script è memorizzato su disco? In questo caso, invece di codificare a fondo la password, potresti leggerla da una variabile ambientale. Questo è più sicuro rispetto all'hard coding direttamente nello script.

Suggerisco di utilizzare qualcosa come keepass, memorizzare nome utente e password e bloccarlo con la password principale (oppure semplicemente crittografare la password del nome utente tramite OpenSSL), ora è necessario proteggere la password principale.

Puoi inserire la password principale nel keystore di Windows o nel portachiavi di Linux e associarla all'account di servizio sul sistema che può eseguire lo script automatico e rilasciare la password principale per accedere a nome utente e password.