Memorizzazione delle chiavi private dell'utente nel DB

2

Ho la necessità di memorizzare le chiavi private per più utenti, in modo che la mia applicazione server possa firmare i file per loro conto. Voglio conservare queste chiavi in modo sicuro, ma non sono riuscito a trovare molte informazioni su questo argomento.

Devo anche supportare la funzione classica "Ho perso la mia password" - se un utente perde la sua password, dobbiamo essere in grado di generarne uno nuovo e la chiave privata non va persa.

Quali sono le migliori pratiche in questi scenari?

P.S. Una domanda molto simile è stata posta su SO 3 anni fa .

    
posta lautaro.dragan 27.10.2017 - 08:49
fonte

3 risposte

1

Vorrei MAI archiviare questo tipo di informazioni senza l'assistenza di un HSM.

Per quanto riguarda le tue esigenze, vault forma hashicorp può farlo (con l'aiuto di un HSM) .

Tuttavia la tua applicazione non dovrebbe ottenere direttamente le chiavi ma dovresti chiedere a vault di fare la crittografia per te.

Implementa anche misure di sicurezza e altre barriere di sicurezza per limitare gli abusi dal momento che trasferisci "dati" con gli "utenti attendibili" allegati una volta che sono firmati dal tuo sistema.

    
risposta data 27.10.2017 - 12:23
fonte
5

IMHO hai un design discutibile qui. Quando leggo

my server application can sign files on their [my users] behalf

tutte le luci lampeggiano improvvisamente in rosso. Se la tua applicazione può firmare qualcosa per conto di un utente, tu firmarlo. Potrebbe andare bene nel tuo caso d'uso, ma dovresti esaminare attentamente la catena di responsabilità. Se in aggiunta devi essere in grado di recuperare la chiave privata se gli utenti perdono la password, significa che hai accesso completo a quella chiave anche senza che gli utenti ne siano stati informati (o senza il loro esplicito consenso). Ciò significa anche che anobody con privilegi di amministratore sul server può firmare qualsiasi cosa per conto di qualsiasi utente. IMHO, le chiavi non appartengono più agli utenti ma sono solo informazioni personali che è necessario proteggere dalla divulgazione indesiderata. La protezione comune è quindi a strati:

  • sicurezza fisica per proteggere la macchina
  • regole di sicurezza interne per identificare chi ha i privilegi su cosa
  • sicurezza di rete per proteggere il sistema dagli accessi remoti
  • più livelli software in modo che un utente malintenzionato debba interrompere almeno due punti di sicurezza per accedere alle informazioni: ad esempio, i dati riservati devono essere archiviati in forma crittografata, in modo che l'utente malintenzionato debba accedere a entrambi i dati crittografati < strong> e la chiave di decrittografia
risposta data 27.10.2017 - 12:11
fonte
0

Ci sono un paio di problemi di utilizzo qui.

  • I tuoi utenti hanno davvero bisogno di accedere nuovamente a quella chiave privata se dimenticano la loro password? Cioè potresti invece non generare una nuova coppia di chiavi e dire loro che hanno bisogno di distribuire una nuova chiave pubblica?
  • L'applicazione ha bisogno di accedere alle chiavi senza che l'utente sia presente?

Se la risposta a entrambi è no, puoi semplicemente crittografare con la loro password. Questo è sicuro come si può ottenere - se un attore malintenzionato ha la sua password (ignorando due fattori) può semplicemente accedere al servizio come loro comunque.

Se una delle risposte è sì, il meglio che puoi fare è crittografare tutte le chiavi utente con la stessa chiave. Vuoi anche prendere in considerazione la struttura di sicurezza architettonica. Cioè dovresti mantenere il database su una macchina separata per l'applicazione, firewall fuori da Internet (idealmente accetta solo connessioni dall'IP del server web server) e firewall per avere solo la porta DB aperta.

    
risposta data 27.10.2017 - 10:54
fonte

Leggi altre domande sui tag