Quanto è pericoloso archiviare la password con hash nella memoria locale?

È molto pericoloso.

L'utilizzo della memoria locale per archiviare gli identificativi di sessione non è mai raccomandato in quanto i dati sono sempre accessibili da JavaScript .

Per favore usa i cookie per mitigare questo rischio usando il flag httpOnly .

Un singolo attacco XSS (Cross Site Scripting) sarà in grado di rubare tutti i dati in questi oggetti e / o caricare informazioni dannose, quindi non considerare la "memoria locale" attendibile e meno per un identificativo di sessione / password hash.

Rif: link

Ci sono diversi problemi con questo.

Innanzitutto, il valore SHA-256 salato è equivalente alla password; qualsiasi utente malintenzionato che ottiene l'accesso a tale valore può semplicemente passarlo direttamente al server per l'autenticazione. Non c'è bisogno di forzare l'hash.

In secondo luogo, utilizzando la memoria locale invece di un cookie contrassegnato con httpOnly significa che questo valore equivalente alla password è potenzialmente vulnerabile ad essere rubato dagli attacchi XSS. Qualsiasi script in esecuzione sul tuo sito ha pieno accesso a questi dati.

E in terzo luogo, un singolo round di SHA-256 è una cattiva scelta per l'hashing della password, in quanto può essere forzato brutalmente con relativa facilità. È del tutto possibile che qualsiasi utente malintenzionato che riesca a ottenere una sospensione dell'hash eseguirà la brute-force per ottenere la password dell'utente, quindi utilizzerà tale password per attaccare gli account dell'utente su altri siti (presupponendo che l'utente riutilizzi le password tra siti, che purtroppo è piuttosto comune).

pericoloso. Non consigliato.

Alcuni motivi per cui;

1. Attacchi MITM. Nel caso di un attacco di canale laterale, un downgrade, riempimento o debolezza della cifratura nell'algoritmo di crittografia che invia una password con hashing sulla linea può essere forzato bruto una volta acquisito.

2. Plugin del browser dannosi / vulnerabili. Esistono migliaia di plug-in personalizzati in esecuzione sui browser dei tuoi clienti. Alcuni di questi sono progettati per fare cose cattive mentre altri storicamente si sono dimostrati insicuri portando a ulteriori informazioni che rubano dal browser.

3. DOM rebinding & Attacchi XSS. Le debolezze nel codice cliente possono aiutare gli aggressori a rubare le credenziali memorizzate nel browser.

4. Vulnerabilità nel browser. Qui un browser vulnerabile può anche portare al furto di credenziali. Tipicamente utile per i tipi di attacco di replay di sessione.

Alcuni modi per proteggere i tuoi clienti;

1. NON CONSERVARE LE INFORMAZIONI SENSIBILI NEL BROWSER DEL CLIENTE.

2. Avvolgi il tuo recapito di codice in una connessione TLS con cifrari forti e niente più vecchio di v1.2. Ciò richiede chiavi forti, ECC / RSA superiori a 2048 bit, niente di meno che un algoritmo SHA512 per i certificati x509.

3. Configura la tua applicazione per rafforzare la sicurezza utilizzando le opzioni content-security-header .

4. Assicurati che la tua applicazione non rilevi dati sensibili o se sviluppi un identificatore per assicurarti che nessun elemento sensibile lasci il server.

5. Mantieni aggiornato il tuo server e le applicazioni, incluso il firmware.

Questo approccio è strettamente meno sicuro rispetto all'archiviazione di un token / cookie di sessione standard e all'invio della password in testo semplice.

Prima di tutto, la password con hash del client funziona come una sostituzione della password, quindi l'effetto di sicurezza sul lato server è irrilevante. In caso di violazione dei dati del server, l'unica cosa che questo hashing sul lato client impedirà è che l'utente malintenzionato veda la tua password originale, che dovrebbe essere già casuale e unica utilizzando un gestore di password. Un utente malintenzionato sarà comunque in grado di autenticarsi inviando direttamente la password con hash al server.

Se questo fosse l'unico problema, sarebbe sicuro come un'autenticazione standard + password univoca casuale, ma poiché la password hash è memorizzata nella memoria locale, aumenta anche la possibilità che la password si scarichi. Qualsiasi attacco semplice che accede alla memoria locale darà via la tua password con hash, che ora può essere utilizzata per accedere (vedi il mio primo punto).

In terzo luogo, un singolo round di SHA256 non è affatto sicuro. Qualsiasi attaccante determinato romperà una password di media lunghezza in un tempo molto breve, e non vi è alcuna sicurezza attraverso l'oscurità poiché il codice javascript è visibile a chiunque abbia accesso al sito web, il che significa che un utente malintenzionato non dovrà nemmeno trovare quale algoritmo è stato utilizzato e quanti giri sono stati eseguiti.

Per ulteriori informazioni sul perché l'hashing lato client è un'idea brutta / superfluo, vedi questo: Hash password lato client

Alla fine, la cosa più preoccupante è che quegli sviluppatori stanno seguendo un approccio non standard, e questo mi farebbe pensare due volte prima di usare il loro sito web.