Quanto è sicuro memorizzare la password crittografata nella memoria locale HTML5?

Question

Quanto è sicuro memorizzare la password crittografata nella memoria locale HTML5?

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

5

Sfondo

Sto cercando di sviluppare un'applicazione web in cui un utente sarà in grado di accedere utilizzando la propria password "P" e al momento del login può creare una password principale "MP". MP può essere utilizzato per aprire / chiudere un vault (in modo simile ai gestori di password) in cui l'utente può memorizzare informazioni riservate. Dopo aver svolto alcune ricerche sull'argomento, ho deciso di garantire quanto segue:

La password principale MP non viene mai memorizzata su / inviata al server
Tutte le crittografie / decrittografie vengono eseguite sul lato client (nel mio caso quello è il browser)

Ora come sto memorizzando il tasto MP '(definito sotto) in memoria, il vault è essenzialmente chiuso ogni volta che il browser viene aggiornato o l'utente apre il sito su una nuova scheda. Come posso mantenere aperto il vault fino a quando l'utente lo desidera? Cookie non è una soluzione in quanto ciò causerà l'invio di MP 'al server ad ogni richiesta; tuttavia, l'archiviazione locale HTML5 può essere una possibilità

Ora, se un hacker capita di accedere all'archivio locale, otterrebbe MP 'e può decodificare tutte le informazioni sensibili che lo utilizzano. Come soluzione ecco cosa sto pensando:

Quando il vault viene aperto, il client richiede una sola chiave casuale 'Rk' dal server
Il server genera Rk, lo memorizza nella sessione dell'utente e lo invia al client
Il client usa Rk per crittografare MP 'per ottenere MP' '
MP "" è memorizzato nella memoria locale HTML5 mentre Rk è conservato in memoria
Quando necessario, MP '' può essere decifrato usando Rk e usato per le operazioni successive
Durante l'aggiornamento del browser, il client recupera Rk dal server (il server restituisce semplicemente quello già memorizzato nella sessione)
Rk è scaduto se l'utente chiude esplicitamente il vault o termina la sessione disconnettendosi

La domanda

Quanto è sicura questa soluzione? Qualche ovvio avvertimento che mi manca? Quale sarebbe l'approccio ideale per risolverlo?

Note aggiuntive

Per la tua comprensione, ecco una breve panoramica di come sto pianificando di soddisfare i miei bisogni:

L'utente crea un nuovo MP
MP è crittografato con un algoritmo di allungamento della chiave per produrre MP '
MP 'è usato come chiave per crittografare un valore noto V per ottenere Vh (ovviamente V ≠ MP o MP')
Vh è memorizzato sul server rispetto al record dell'utente

Vh ha 2 scopi:

Indica che l'utente ha già creato un MP. Se ancora non c'è, posso chiedere all'utente di crearne uno nuovo
Ogni volta che l'utente inserisce MP per aprire il vault, posso recuperare Vh dal server e provare a decrittarlo con MP '. Se la decrittografia ha esito positivo, suppongo che l'utente abbia inserito l'MP corretto

Come puoi immaginare ecco come dovrebbe funzionare il resto:

Ogni volta che l'utente desidera memorizzare / recuperare informazioni sensibili:

Eseguono il login usando P e aprono il loro vault con MP
Il client produce MP 'come accennato in precedenza
Le informazioni sensibili vengono crittografate utilizzando MP 'prima di essere inviate e memorizzate sul server
In base alle necessità dell'utente, le informazioni sensibili crittografate vengono recuperate dal server (così com'è)
Il client utilizza MP 'per decrittografare i dati

passwords

posta Tanvir 21.06.2017 - 00:54

fonte

2 risposte

Leggi altre domande sui tag passwords

Misterioso dispositivo in rete, serve qualche suggerimento Tipi MIME che consentono XSS nei browser moderni

score 2 · Answer 1

Ci sono diversi problemi con il tuo approccio:

1) Inoltra segretezza. Supponiamo che l'attaccante possa monitorare la comunicazione (tramite proxy https hackerato o altro). In un secondo momento l'utente cancella l'account e rivela MP come ritiene che sia inutile. Utilizzando i dati registrati e MP tutte le informazioni possono essere ripristinate dall'attaccante perché si sta crittografando il vault con MP '.

2) Non è chiaro come difendersi dal compromettere P. Capturing P (che va sulla rete) l'utente malintenzionato può accedere, acquisire Rk e decifrare MP ", a meno che Rk non venga rigenerato a tutti gli accessi, ciò significa che l'utente sarà effettivamente disconnesso se chiude il browser (potrebbe essere ok e inteso, non lo so). In ogni caso, è meglio non inviare P (vedi idee qui di seguito).

3) La crittografia offre un miglioramento limitato della sicurezza. Se l'utente malintenzionato può accedere a localStorage, probabilmente ha accesso fisico e / o ha compromesso il tuo computer, quindi sei condannato comunque (stai affrontando keylogger, iniezioni di script locali, qualunque cosa). La crittografia ti aiuterà se il disco rigido viene rubato o se l'hacker è in grado di falsificare il tuo dominio (ad esempio l'avvelenamento della cache DNS). È meglio non memorizzare la password in primo luogo.

Diverse idee:

per mitigare (1) utilizzare le chiavi della sessione one time per crittografare tutti i messaggi. Ad esempio, è possibile utilizzare la crittografia asimmetrica per inviare al server una chiave di sessione casuale (crittografata con la chiave pubblica del server). In alternativa, potresti voler applicare le sessioni SSL appropriate (informando ed educando i tuoi utenti) poiché SSL ha una buona segretezza in avanti.
per (2) invece di usare P per autenticare, usa un metodo avanzato es. OAuth, preferibilmente 2FA.
potresti prendere in considerazione l'uso di sessionStorage invece di localStorage che è garantito che verrà cancellato al riavvio del browser (altri modi è molto simile ai cookie senza rete). Non sono sicuro che tutte le implementazioni (o altre) possano rimuovere in modo sicuro tutte le tracce dello storage all'uscita, quindi la crittografia potrebbe essere comunque una buona idea.

score 0 · Answer 2

Penso che valga la pena rivalutare la tua premessa. Presumibilmente, vuoi cifrare le cose lato client in modo che il server non abbia accesso ai dati non crittografati, ma non è proprio così, e penso che finisca per essere più teatro della sicurezza rispetto alla sicurezza reale.

Questo è del 2011, ma penso che il problema principale qui sia ancora pertinente, se non ci si può fidare del server per gestire correttamente la crittografia dei dati (cioè crittografarlo e quindi dimenticare il testo in chiaro e la password), allora come si può fidarsi di ciò per consegnare il codice che deve gestire il lato client di crittografia?

Sembra che questo potrebbe essere di beneficio nel caso di un compromesso che permetta all'utente malintenzionato di leggere le richieste senza modificarle, ma si sta ancora riponendo tanta fiducia nel server che non sono convinto ne valga la pena.