Come memorizzare la passphrase in questa situazione?

Innanzitutto, il login deve essere rilasciato per cliente, quindi può essere modificato se trapelato o cancellato quando viene revocato l'accesso di un cliente al servizio. Questo riduce le conseguenze della perdita della password alla dimensione più piccola, invece di perdere tutto quando un client viene compromesso o diventa canaglia.

Dopo averlo fatto, il tuo problema è semplicemente quello di memorizzare una password che viene utilizzata per questo cliente con questo unico servizio. Questo è un problema ben noto con soluzioni note. In sostanza, si dovrebbe assumere che il sistema operativo sia sicuro. (Se non si dispone di problemi più grandi.) Quindi salvarlo in un file, il registro ecc. E proteggerlo con un ACL. Se lo desideri, puoi aggiungere l'offuscamento o utilizzare CryptProtectData o simili, che possono fornire una protezione contro gli aggressori non sofisticati.

Ma la linea di fondo è che devi accettare che emettere, revocare e resettare le credenziali sarà una parte normale della tua operazione. Dovrai anche monitorare l'utilizzo del servizio in modo da poter rilevare quando le credenziali sono trapelate.

È difficile da raggiungere senza lasciare un livello ragionevolmente significativo di rischio (se l'host dovesse essere compromesso in qualche modo), sebbene possa essere in qualche modo mitigato.

Le credenziali HTTP devono essere crittografate tramite un algoritmo simmetrico strong (e ben definito), che richiederebbe una password per la decrittografia. Poiché sarà necessario decrittografare la password senza che sia presente un operatore, la chiave dovrà essere disponibile da qualche parte, il che è il punto debole di questo metodo. Vorrei sconsigliare di codificare a fondo questi dettagli, poiché tutti potrebbero essere rivelati se qualcuno ha messo le mani sui file dell'applicazione. Invece, consiglierei all'utente di chiedere le credenziali HTTP e una password di crittografia durante l'installazione / primo utilizzo. L'applicazione richiederebbe quindi la password di crittografia ogni volta che viene avviata, che verrà archiviata in memoria fino al termine del processo di applicazione. Ciò richiederebbe un operatore durante la prima installazione e per ogni riavvio ecc.

(Nb Si consiglia di utilizzare gli array di caratteri per le variabili di password anziché le stringhe dovute alla garbage collection in Java. Vedi qui: link )

Tuttavia, una soluzione più comoda - che si basa sull'applicazione utilizzata esclusivamente su Windows, ma sostanzialmente gestisce tutto quanto sopra per voi - sarebbe di utilizzare DPAPI . Questo in pratica crittografa e memorizza le credenziali utilizzando i dettagli dell'account Windows, quindi l'applicazione dovrebbe essere in grado di recuperare le credenziali HTTP a condizione che venga eseguita da un utente che le ha archiviate tramite DPAPI. Questo ha dei punti deboli simili a quelli della soluzione interna, ma evita le insidie nell'implementazione del proprio cripto-sistema.

A quanto pare, la tua principale vulnerabilità in questo modello è la rete: spendere tempo e denaro nel tentativo di archiviare dati che viaggiano in testo chiaro è una perdita di tempo (e denaro).

Tipicamente, tenterai di risolvere quel tipo di problema aggiungendo un livello di sicurezza attorno alla parte vulnerabile: se non puoi ottenere il sistema remoto per usare HTTPS, quindi usa una VPN che si avvicini il più vicino possibile alla destinazione server (perché chiunque abbia accesso alla rete tra quell'endpoint VPN e il server HTTP sarà in grado di ottenere i dati in chiaro).

Un'altra opzione è quella di posizionare entrambi i sistemi nella stessa rete temprata. (Questo di solito ha senso solo se disponi già di una rete di questo tipo).

Una volta assicurata la rete, puoi pensare a proteggere queste chiavi (anche se, nel tuo caso, potrebbe ancora essere inutile se il sistema remoto non tratta questa chiave in modo sicuro).

Codificalo in Base64 mantieni il risultato in una variabile e decodificalo quando necessario. Ciò manterrà gli script-kiddies via, ma non riposi.