Hash sul lato client della password prima di inviarlo dal modulo di accesso [duplicato]

3

Mi sono appena reso conto che la mia applicazione web sta inviando password non crittografate dal modulo di accesso. È proprio così - ho analizzato, quella stringa inviata dall'utente dal modulo di login è stata sottoposta a hashing con MD5 (che è sbagliato in sé - ma questa è una storia diversa) sul lato server e confrontata dopo (password in DB sono hash ).

Ho sollevato il problema nel mio tracker di problemi interni, che questo dovrebbe essere sostituito con l'uso della lib di Javascript per la password di hash direttamente nel modulo di login, quindi non sarebbe mai stato inviato in chiaro. Ho ricevuto immediatamente un commento da uno dei nostri sviluppatori, che è sbagliato, perché richiede all'utente di abilitare Javascript. E, questo problema dovrebbe essere risolto usando HTTPS, non dalle password di hashing sul lato client.

Ho la mia opinione personale su tutto questo crap " richiede Javascript abilitato ", che a questo punto non è importante. Ma mi piacerebbe avere una risposta chiara, quale di noi è sbagliato. È davvero costringere l'utente ad abilitare Javascript un peccato più grande, piuttosto che inviare la sua password al server? E per quanto riguarda la situazione, quando la mia applicazione verrà eseguita su HTTP, non sul server HTTPS (per molti motivi)?

    
posta trejder 02.07.2014 - 13:26
fonte

3 risposte

7

Dal punto di vista dell'attaccante, se invii una password in testo semplice o un hash MD5 o non faccia molta differenza, purché l'invio dello stesso valore sblocchi di nuovo la porta. Ricorda, entrare è l'obiettivo principale, non ottenere il valore esatto della password. Quindi se l'attaccante intercetta la password con hash, l'invio di nuovo dalla sua casella produce lo stesso risultato - login accettato. L'utilizzo di HTTPS sarebbe la soluzione migliore, in quanto protegge tutti i dati.

EDIT: Per quanto riguarda la situazione in cui la tua applicazione sarà accessibile su un semplice HTTP - beh, allora sei fregato. A meno che non carichi il tuo protocollo ( NON RACCOMANDATO ) per crittografare la password lato client e decifrare, hash e convalidarlo lato server, la password verrà esposta.

    
risposta data 02.07.2014 - 13:37
fonte
6

link

    
risposta data 02.07.2014 - 13:40
fonte
0

Secondo me l'invio di una password in chiaro è un peccato e un rischio più grande perché l'hacker avrà bisogno di meno esperienza (cioè di annotare la password in chiaro dal server) rispetto all'uso di javascript (l'hacker avrà bisogno di più competenze). e inoltre, perché non proteggere i tuoi cookie, invece? piace non contrassegnare i cookie come httponly?

    
risposta data 02.07.2014 - 13:32
fonte

Leggi altre domande sui tag