hashing JavaScript nelle chiamate di accesso AJAX, più sicurezza?

Question

Da molti post che ho visto sul sito, gli accessi eseguiti da AJAX o moduli tradizionali sono altrettanto sicuri l'uno dell'altro. (Re: Login/session cookies, Ajax and securityAjax login and javascript cookies, is this secure?)

La mia domanda (s) è/sono:

1. Se hash della password dell'utente (tramite client-side/javascript hash librerie) prima di inviare al server , posso aumentare la sicurezza dalle persone easedropping?

2. Se inserisco un token modulo (uno a caso basato, un altro a base di tempo), copre gli attacchi CSRF?

3. Avrei tutte le mie basi coperte dopo tutto questo? Questa forma sarebbe sicura?

Answer 1

In realtà questo potrebbe essere un grosso problema di sicurezza. Il motivo per cui le password sono hash è un modo di pianificare il fallimento. Un utente malintenzionato potrebbe accedere all'archivio dati (SQL injection) e quindi ottenere l'hash. Se si sta effettuando il login con un hash, l'hacker non deve crackare l'hash recuperato per poter accedere all'applicazione.

attacchi Replay sono anche un problema. Se annuso l'hash durante l'autenticazione, che cosa mi impedisce di riprodurre semplicemente la richiesta di autenticazione?

I protocolli che utilizzano le funzioni di digest del messaggio per l'autenticazione forniscono al client un nonce, che viene utilizzato come una volta salt. L'autenticazione NTLM SMB di Microsoft è un buon esempio, ma ha avuto a lot of problems.

USE SSL, e non solo per il login. OWASP A9 afferma che l'ID di sessione non deve mai essere divulgato su un canale non sicuro. Dopotutto, chi se ne importa della password se si versano le autentiche credenziali di autenticazione qualche millisecondo dopo.

La maggior parte delle persone non implementa la protezione CSRF per l'accesso. Dopotutto l'attaccante dovrebbe conoscere la password in primo luogo, quindi "la sessione di guida" è un punto controverso.

Answer 2

Se l'utente malintenzionato conosce l'hashing che si sta utilizzando, può craccarlo. E se vuoi aggiungere un sale devi inviarlo al browser e l'attaccante potrebbe intercettarlo. Anche l'uso del tempo come sale non funzionerà perché c'è solo una quantità relativamente breve di tempo in modo che possano risolvere anche questo.

Answer 3

Un po 'da parte, ma in risposta alla domanda 3. NO! Ricorda inoltre che i moduli AJAX e standard sono ugualmente uguali a insicuri.

L'implementazione dell'autenticazione sicura è difficile. A meno che tu non stia facendo un esercizio accademico, ti consiglio vivamente di utilizzare la libreria fornita dal tuo framework, se sei abbastanza fortunato da averne uno buono.

Sarà inoltre necessario prendere in considerazione aspetti come il seguente e altro.

• Implementare un id di sessione opportunamente casuale e non accessibile da utilizzare nel cookie di sessione.
• Non consentire all'ID di sessione di essere forzato.
• Quando le autorizzazioni o le credenziali vengono modificate (ad es. Perché l'utente ha effettuato l'accesso o l'uscita), allora annulla immediatamente la sessione e ne avvia una nuova.
• Fornire una funzionalità di disconnessione e assicurarsi di invalidare la sessione al termine del logout.
• Imposta il cookie su HttpOnly -Preferibilmente richiede HTTPS e alo imposta il cookie solo su secure.
• Considerare di limitare la validità della sessione per includere il controllo di altre informazioni che aiutano a far corrispondere l'utente, ad es. agente utente.
• Scadono sempre le sessioni dopo il mancato utilizzo e non implementano "mantieni il login" ricollegando l'utente alla loro precedente sessione http.
• Assicurarsi che 2 sessioni non possano avere lo stesso ID di sessione allo stesso tempo
• Assicurarsi che tutti i dati di sessione vengano distrutti quando una sessione viene invalidata. Un nuovo utente che arriva, può capitare che venga assegnato un ID di sessione che è stato usato in precedenza. Questa nuova sessione non deve avere alcun accesso ai dati di sessione che sono stati precedentemente impostati rispetto a quell'ID di sessione.