GWT/Javascript crittografia della password lato client

Question

sto implementando autorizzazione nella mia app GWT, e in questo momento è fatto nel modo seguente:

1. l'utente si inscrive mettendo le sue credenziali in forma, e Li mando in chiaro al server.
2. Il codice del server esegue l'hashing della password ricevuta utilizzando BCrypt e inserisce l'hash in un database.
3. Quando l'utente esegue il login, la sua password viene inviata in chiaro al server, che la controlla contro l'hash memorizzato.

Ora. La cosa che mi infastidisce di questo è il fatto che sto inviando la password al server in chiaro, continuo a pensare che non sarei molto contento se un'applicazione che stavo usando lo abbia fatto con il mio (uso-per- tutto-gentile) password, ma la crittografia sul client non mi guadagnerebbe nulla, dal momento che gli hacker potevano semplicemente usare la password con hash come se fosse quella chiara.

Sono stato googling tutto il giorno per questo, e sembra che Internet sia piuttosto unanime quando si tratta di questo - apparentemente non c'è nulla da guadagnare dalla crittografia della password lato client. This, this e sono solo alcuni esempi delle discussioni e delle pagine in cui sono arrivato, ma ce ne sono molti, molti altri, tutti che dicono la stessa cosa.

Questa domanda, alla luce di tutto questo, potrebbe sembrare un po 'inutile, ma spero che da qualche parte, qualcuno, avrà un'altra risposta per me.

Cosa posso fare, se SSL non è un'opzione a questo punto, per alleviare la mia idea su questo? C'è qualcosa da fare o implementare una sorta di schema di decrittazione del server client-crittograficamente poco costoso?

Answer 1

Per il login, SSL dovrebbe essere la tua opzione, anche a questo punto.Se è solo per il login, non è necessaria una costosa farm SSL, ma almeno si protegge la password (use-for-everything-kind), anche se è chiaro, che la comunicazione rimanente non è protetta ^[*]. Ciò potrebbe significare che è necessario acquistare un certificato per un solo server di accesso, che può di nuovo risparmiare un sacco di soldi, a seconda del fornitore del certificato.

Per GWT, se non puoi permetterti di crittografare tutte le comunicazioni, dovrai mettere il login su una pagina separata a causa dei vincoli della stessa politica di origine.

Se non è ancora un'opzione, è possibile pensare di accedere tramite OpenID, proprio come fa StackOverflow.

Non ci può essere qualsiasi comunicazioni sicure sui mezzi insicuri senza alcuni pre-segreto condiviso - di solito fornita dai certificati di origine che sono installati in un browser (a proposito, è divertente/paura che i browser e perfino intere i sistemi operativi vengono solitamente scaricati tramite HTTP). Altri sistemi, ad es. PGP, fare affidamento su trust precedentemente stabilito in un "Web Of Trust", ma questa è solo un'altra forma di segreti pre-condivisi. Non c'è modo di aggirarlo.

^{[*] L'utilizzo di SSL per tutto, purtroppo, è accompagnato da ulteriori problemi pratici: 1) I carichi di pagina sono molto più lenti, soprattutto se nella pagina sono presenti molti elementi. Ciò è dovuto ai round trip indotti da SSL e alla conseguente latenza, che non è possibile contrastare nemmeno con la farm SSL più veloce. Il problema è mitigato, ma non completamente eliminato dalle connessioni keep-alive. 2) Se la tua pagina include elementi provenienti da siti stranieri non HTTPS (ad esempio immagini inserite dagli utenti), molti browser visualizzeranno avvisi, che sono molto vaghi riguardo al reale problema di sicurezza, e pertanto sono solitamente inaccettabili per un sito sicuro.}

Qualche considerazione aggiuntivi (non una raccomandazione)

Supponiamo il caso peggiore per un momento, vale a dire che non è possibile utilizzare SSL a tutti. In tal caso, forse sorprendentemente, l'hashing della password (con un salt) prima di trasmetterlo, potrebbe effettivamente essere un po 'meglio che non fare nulla. Ecco il motivo: non può sconfiggere Mallory (in crittografia, una persona che può manipolare la comunicazione), ma almeno non permetterà a Eve (una persona che può solo ascoltare) di leggere la password in chiaro. Questo può valere qualcosa, se supponiamo che Eves sia più comune di Mallorys (?) Ma nota, in questo caso dovresti cancellare la password di nuovo (con un sale diverso), prima di confrontarla con il valore del database.

Answer 2

Se SSL non è un'opzione, allora ovviamente non si cura abbastanza di sicurezza;)

Ma sul serio - come lei ha ricordato, la crittografia lato client della password non è una buona idea. In realtà, è molto brutto. È non fidarsi del lato client per il jack - cosa succede se un utente malintenzionato è riuscito a modificare il codice JS (tramite XSS o mentre è stato inviato attraverso il filo), in modo che MD5/qualunque funzione hash passi semplicemente il passaggio in chiaro ? Senza contare che si dovrebbe usare un metodo di crittografia buono, forte e salato, come bCrypt - qualcosa che è solo lento sul client e come accennato prima, non aggiunge abbastanza alla sicurezza dell'app.

Si potrebbe provare a evitare alcuni di questi problemi: inviando la libreria di hash attraverso alcuni mezzi sicuri (se fosse possibile in primo luogo, non dovremmo preoccuparci di tutto questo ora, vero?), la condivisione di un segreto in qualche modo comune tra il server e il client e l'utilizzo che per la crittografia ... ma la linea di fondo è: utilizzare HTTPS quando possibile (in GWT è difficile mescolare HTTPS e HTTP) e giustificato (se il l'utente è abbastanza stupido da usare la stessa password per la tua app non legata alla sicurezza e per il suo conto bancario, quindi è molto probabile che abbia usato la stessa password su un certo numero di altri siti, ognuno dei quali potrebbe portare a dirottare il parola d'ordine). Altri mezzi ti faranno solo pensare che la tua applicazione sia più sicura di quanto non sia e ti rende meno vigile.

Answer 3

Considerare l'utilizzo di SRP.

Ma questo non è ancora d'aiuto se un uomo nel mezzo ti manda un javascript malvagio che semplicamente manda una copia della tua password al server degli hacker.