Sessione: memorizzazione di una password della chiave di crittografia

Question

Sessione: memorizzazione di una password della chiave di crittografia

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

1

Per una webapp che memorizza i file crittografati, una chiave pubblica viene utilizzata per crittografare le chiavi / ivs casuali, che vengono utilizzate per crittografare i file memorizzati. La chiave privata, utilizzata per la decodifica, è protetta da una password che deve essere fornita dall'utente per accedere ai file (la natura del sistema è tale che solo un utente ha / ha bisogno della possibilità di accedere ai file non crittografati).

Per evitare che l'utente debba digitare la password della chiave privata su ogni caricamento della pagina, deve essere memorizzato (ad esempio, per 10 minuti). La domanda è, dove / come memorizzarla?

Inserirlo in un cookie è analogo all'utente che lo scrive su ogni richiesta, quindi è un vantaggio. Ma, poi qualcuno con accesso a il loro computer potrebbe guardare i dati del loro browser e vedere / recuperare la chiave in testo normale. Inoltre, spetta al browser espirarlo in tempo (cosa che potrebbe scegliere di non fare)
D'altra parte, potrebbe essere memorizzato nei dati di sessione sul server. Questo dà un controllo migliore sulla sua scadenza e significa la chiave non sta volando su Internet ad ogni richiesta (ovviamente, questo è tutto su https, ma ancora). Ma questo significa archiviare il password, la chiave e tutti i dati sulla stessa macchina (anche se temporaneamente), che non sembra neanche così bello.

Uno di questi è oggettivamente migliore? C'è un'alternativa migliore di entrambi?

rails public-key-infrastructure

posta frostcoinage 10.11.2017 - 19:21

fonte

2 risposte

Leggi altre domande sui tag rails public-key-infrastructure

Quale secondo fattore è stato accettato su un'app mobile? Un sito Web invia il campo delle credenziali dell'account come "vuoto"

score 1 · Answer 1

Se stai memorizzando la chiave nella cache, ci sarà sempre un rischio alcuni .

Questo rischio può essere mitigato da:

Limitazione della quantità di tempo in cui la chiave viene conservata in memoria
Limitazione della memoria dinamica solo in modo che venga persa alla chiusura della pagina
Uso di un hardware o di un keystore virtuale per rendere l'accesso alla chiave più facile ma più sicuro. Ubikey o archivio certificati di Windows potrebbero essere esempi.

Le chiavi private NON DEVE MAI essere memorizzate su un server a meno che non siano esse stesse crittografate con una chiave che solo l'utente ha (rendendo il processo piuttosto ridondante). Una volta che una chiave privata degli utenti è memorizzata su un server, non può più essere considerata sicura.

score 0 · Answer 2

Stai facendo molte ipotesi, molte delle quali sono sbagliate. Il più clamoroso è che il browser ha il controllo esclusivo su quando il cookie è scaduto. Puoi eliminarlo in una risposta del server ogni volta che vuoi. È possibile memorizzare più di un pezzo di dati in un cookie (come un tempo di scadenza e una firma per proteggere dalle modifiche.) Se qualcuno ha accesso alla memoria e all'archiviazione sul client durante una sessione, ha accesso ai dati che si sono cercando di proteggere. Non è necessario memorizzare il testo in chiaro della chiave sul client per consentire la decodifica sul server (è possibile utilizzare un'ulteriore chiave di sessione generata sul server, anche se l'obiettivo di non utilizzare una sessione http convenzionale non è correlato alla capacità, quindi c'è una piccola differenza per mantenere solo la chiave serveride.

L'uso di una sessione http semplifica molti altri problemi (come csrf).

Per quanto riguarda quale di questi è migliore o cosa potrebbe essere più appropriato, ciò dipende dal modello di minaccia.