Devo usare l'algoritmo MD5 sia in JavaScript che in PHP per l'autenticazione di login?

Se ignoriamo la scelta effettiva dell'algoritmo e consideriamo la domanda: "Dovrei eseguire l'hash su lato client e server?"

L'hashing in Javascript è completamente inutile poiché l'idea è di proteggere contro la password che viene sniffata durante il trasferimento. Ma se questo è un rischio, la comunicazione con il server non è sicura, il che significa che potrebbe già esserci un attacco man-in-the-middle in corso.

Ciò significa che l'algoritmo di hashing javascript potrebbe essere stato consegnato dall'hacker al posto del server. Ad esempio, l'algoritmo potrebbe inviare la password all'autore dell'attacco.

Quindi, no. Non dovresti eseguire l'hash nel browser ma utilizzare una connessione sicura al server.

Devi inviare la password al server. Se si prende per la prima volta l'MD5 della password e lo si invia al server, l'MD5 diventa effettivamente la password: se l'utente malintenzionato trova l'MD5, sarà in grado di accedere, senza bisogno di trovare di che cosa sia l'MD5.

Quindi è necessario assicurarsi che il proprio codice Javascript (la parte che viene eseguita nel browser, cioè il client) legga la password e la invii al server, dove verrà elaborata dal codice PHP. Assicurati che il campo di inserimento della password sia dichiarato come password, in modo che il browser ti offra di salvarlo nel suo database delle password e non nella cronologia normale.

Per evitare che un utente malintenzionato trovi la password in transito o impersonare il server, devi utilizzare HTTPS . HTTPS crittografa la connessione e consente al client di verificare che stia parlando al server previsto e non a un imitatore che sta cercando di afferrare le password degli utenti. Inoltre, devi utilizzare HTTPS per trasferire tutti i dati che dipendono dalla password: altrimenti un utente malintenzionato potrebbe consentire all'utente di accedere, quindi dirottare le trasmissioni successive.

Sul lato server, nel codice PHP, non usare MD5 normale per cancellare la password. Le vulnerabilità che consentono a un utente malintenzionato di ottenere il database delle password sono molto comuni ( un esempio recente - con una discussione che dovresti leggere ), quindi non pianificare su questo non ti succede mai. La cosa più importante è che devi usare un salt , perché avere un unico salt per ogni password memorizzata impedisce metodi che attaccano molte password contemporaneamente: essenzialmente, quando le password sono salate, l'unico modo per recuperarli dal database delle password è provando ogni possibilità (forza bruta). (Vedi Perché usare sale è più sicuro? per maggiori dettagli.)

Inoltre, MD5, anche se non completamente rotto (ancora), ha molti punti deboli noti. Non usarlo per nulla; utilizzare invece SHA-2 (SHA-256 o SHA-512). Per le password, questo non è l'ideale, perché una buona funzione di hashing della password è lenta : il server legittimo non impiega molto tempo nella verifica della password, quindi puoi permetterti di essere lento; ma un hacker che lavora su un database di password spende tutte le sue password di hashing del tempo, quindi un rallentamento lo colpirà duramente. La raccomandazione generale per l'archiviazione delle password è Bcrypt o PBKDF2 - vedi fai gli esperti di sicurezza consigliano bcrypt per l'archiviazione delle password?

L'hashing sul server e l'hashing sul client attenuano diversi attacchi, quindi è necessario considerare quali attacchi è necessario proteggere.

Hash lato server

L'hashing sul server mitiga il compromesso delle password memorizzate (ad esempio la perdita del database). Se le password non sono associate qui, un utente malintenzionato avrà accesso immediato alle credenziali, consentendo in tal modo l'accesso al server. Memorizzando le password con hash, l'utente malintenzionato è costretto a dedicare ulteriore impegno al recupero delle credenziali effettive.

Hash lato client

L'hashing sul client mitiga gli attacchi sul canale tra il client e il server, nonché sui componenti del server che elaborano le credenziali non elaborate (componente di accesso, password impostata e componente di modifica). Mediante hashing della password sul client, l'utente malintenzionato è costretto a dedicare uno sforzo ulteriore al fine di recuperare la password effettiva. Si noti tuttavia che questo hash è un equivalente in testo normale - se un utente malintenzionato cattura l'hash, può usarlo per autenticare il server.

Il valore qui è nella protezione della password che l'utente ha inserito, dal momento che la maggior parte degli utenti usa la stessa password per altri servizi. Mentre catturare l'equivalente in testo normale comprometterebbe l'account dell'utente sul servizio, non comprometterebbe gli account dell'utente su altri servizi. Ovviamente se tutti i servizi usassero questo schema lo stesso hash sarebbe un equivalente in testo normale per altri siti, e quindi dovrebbe essere aggiunto qui un sale unico per il proprio servizio.

Quindi cosa si dovrebbe fare?

La prima classe di attacchi deve assolutamente essere protetta, dal momento che si verificano perdite di database, e quindi l'hashing lato server è un must. La seconda classe di attacchi è in gran parte mitigata dall'uso di TLS e quindi lo sforzo extra di utilizzare l'hashing del lato client di solito non ne vale la pena.

Gli hash

Come altri hanno già detto, l'uso di MD5 e SHA1 è strongmente scoraggiato. La famiglia di hash SHA2 è di per sé sicura, ma non solo appropriata per l'hashing della password perché sono progettati per essere veloci. Le password devono essere sottoposte a hash con uno schema appositamente progettato per l'hashing delle password, ad esempio bcrypt , scrypt o PBKDF2 . Se uno di questi schemi non è davvero un'opzione, la password deve essere salata e iterativamente con hash con un hash SHA2.

Altri approcci

Esistono schemi come SRP che non memorizzano la password o l'equivalente in testo normale sul server, né trasmettono la password o l'equivalente in testo normale tra client e server.

Non dovresti usare affatto MD5. È stato efficacemente rotto e inutile per l'hashing sicuro. Al giorno d'oggi su un normale computer, puoi generare collisioni MD5 in pochi secondi. SHA-1 è anche abbastanza insicuro in questi giorni (anche se ancora un po 'più duro di MD5, non è troppo difficile da generare collisioni su entrambi), quindi dovresti usare [almeno] un algoritmo hash basato su SHA-2 (SHA-256 o SHA-512).

Le strategie di implementazione specifiche non contano molto se scegli un algoritmo hash che può essere compromesso in pochi minuti da chiunque abbia la possibilità di cercare "crack MD5" su Google.