Se utilizzo SSL, devo cancellare la password prima di inviarla al server? [duplicare]

Question

Se utilizzo SSL, devo cancellare la password prima di inviarla al server? [duplicare]

#1 da (1 voti)

0

Sto creando un sito Web per aiutare le persone con determinati interessi di nicchia a trovarsi l'un l'altro. Viene fatto semplicemente come un progetto volontario, non ci sono soldi in gioco (su entrambi i lati), né ci sono molte informazioni personali memorizzate. Gli unici dati interessanti che memorizziamo sono il codice postale, l'indirizzo email e la password (hash) di ciascun utente. Tutto ciò che si otterrebbe avendo accesso a questi è la possibilità di modificare il codice postale dell'utente, il che mi sembra poco vantaggioso per nessuno.

Tuttavia, è stato sottolineato che molte persone usano la stessa password ovunque, quindi se qualcuno potesse accedere ai dati, sarebbe in grado di provare la stessa combinazione di email / password su altri siti. Anche se questo sembra un compito piccolo e probabilmente futile, vogliamo rassicurare i nostri utenti che li stiamo proteggendo.

Se eseguiamo il sito su SSL, quando registrano o eseguono l'accesso, c'è un grande vantaggio nell'annullare la password in Javascript prima di inviarla al server? D'altra parte, stiamo esponendo tutto ciò che non dovremmo fare eseguendo l'hashing in Javascript, dove è visibile a chiunque, al contrario del server, dove è visibile solo alle persone con accesso al server (nel qual caso abbiamo altri problemi di sicurezza?

P.S. Si prega di notare che io non sono un esperto di sicurezza in alcun modo, quindi per favore non presumere alcuna conoscenza precedente. Se mi è sfuggito qualche punto ovvio, ti preghiamo di chiarirlo o di chiedere maggiori dettagli, piuttosto che fare downvoting come una cattiva domanda. Ho cercato in giro, ma non ho trovato nulla che risponda a questa domanda (anche se ho imparato molte altre cose lungo la strada!)

P.P.S. Si noti che questa domanda è specificamente correlata al registro e alla procedura di accesso. Ci sono ovviamente domande sulla sicurezza del database, ecc., Ma vengono trattate separatamente.

authentication passwords web-application hash

posta Avrohom Yisroel 28.05.2017 - 16:43

fonte

1 risposta

Leggi altre domande sui tag authentication passwords web-application hash

Da un inserimento di file locale in una shell quando il file viene scaricato? Posso forzare le comunicazioni dell'app-server a non utilizzare DHE / ECDHE?

score 1 · Accepted Answer

Generalmente non vi è alcun motivo per crittografare le password lato client. Consideriamo prima una situazione senza SSL, ma con la crittografia della password:

Bob sta effettuando l'accesso al suo account. Va alla pagina di accesso, inserisce il nome utente e la password e accede. Mentre Eve sta monitorando lo scambio, non vede la password, poiché è crittografata.

Questo avverrebbe solo se Eve sta solo monitorando la connessione (che non è quasi mai). Ecco cosa accadrebbe se Eve potesse modificare la connessione:

Bob sta effettuando l'accesso al suo account. Va alla pagina di accesso. Tuttavia, Eve intercetta questa richiesta e rimuove il codice di crittografia. Bob inserisce il nome utente e la password e accede. Mentre Eve sta monitorando lo scambio, fa vede la password, poiché non è crittografata. Per fare in modo che Bob non sospetti nulla, inoltra la richiesta con la password crittografata al server e restituisce il token di sessione a Bob.

In questa situazione, possiamo vedere che la crittografia è inutile quando il codice di crittografia può essere compromesso. Sarebbe utile, tuttavia, quando il codice dell'applicazione può essere considerato attendibile (ad esempio fornito da un CD e firmato dallo sviluppatore) e i dati vengano scambiati su una connessione non sicura (cioè senza SSL). Questo non è il caso di un sito web su HTTP.

Che cosa succede se questo è stato fatto su SSL? Bene, non ci sarebbe ancora alcun punto di crittografia lato client. L'utente malintenzionato non sarebbe in grado di vedere lo scambio e, se fosse stato compromesso, potrebbe essere utilizzato l'attacco mostrato sopra. Inoltre, questo solleva un punto di rotazione della tua crittografia: sì, non stai facendo da soli gli algoritmi, ma stai usando la crittografia da qualche parte dove viene svolta altrove. Inoltre, le persone che hanno disabilitato JS o hanno browser senza l'API crypto, l'intera cosa non funzionerebbe. Il punto di come JS potrebbe essere insicuro non è poi così grave, poiché se non vengono inviati specifici header HTTP, JS sarebbe comunque in grado di afferrare la password.