L'invio di una password crittografata o SHA1 è più sicuro del testo non crittografato?

Suppongo che tu stia parlando di hashing aggiuntivo. Quindi sarebbe simile a questo:

Client --sha1(password)--> Server --bcrypt(sha1(password)--> Database

_{Penso che tu ne sia a conoscenza, ma solo per renderlo esplicito: il trasferimento deve avvenire tramite SSL per difendersi dagli intercettatori, l'hashing client-side non sarebbe di nessun aiuto contro di loro.}

L'hashing o l'offuscamento di una password lato client possono essere una buona soluzione per il riutilizzo della password:

Anche se un utente malintenzionato accede alla password in testo semplice nel trasferimento o sul server, verrebbe comunque sottoposto a hash, quindi un utente malintenzionato non può provare le stesse credenziali su altri siti Web senza aver prima craccato l'hash.

It seems to me that if an attacker can intercept my login request, then he can replay it later, no matter whether I try obfuscate it or not.

Sì. L'hashing lato client non aggiunge alcuna sicurezza all'applicazione tua , l'unico vantaggio è che attenua il cattivo comportamento degli utenti, il che può influire su altre applicazioni che l'utente sta utilizzando.

Si noti che non protegge nemmeno la propria applicazione dal riutilizzo della password, in quanto un utente malintenzionato che ha acquisito le credenziali degli utenti da un'altra applicazione lo ha solo cancellato e provato.

Inoltre non aggiunge alcuna complessità al processo di cracking degli hash memorizzati. Un utente malintenzionato non proverebbe un elenco di hash come input, ma una normale lista di parole, che passerebbe prima attraverso sha1.

Come ha scritto tim, potrebbe aiutare a mitigare gli effetti del riutilizzo della password per gli utenti in alcuni casi, ma se quello che stai pensando è l'hashing del lato client invece di sul lato server, questo sarebbe un grande difetto di progettazione.

link

Questo problema affligge l'autenticazione NTLM, in cui è addirittura peggiore rispetto allo scenario di servizio / applicazione Web comune, poiché gli hash vengono spesso memorizzati nella cache su sistemi diversi dal server che gestisce l'autenticazione.

La tua password sha1 diventa semplicemente la semplice password per un eyedropper.

Quello che faccio è il seguente:

Sul database, ogni password è crittografata con bcrypt e salt. Il sale è "pubblico".

Quando l'utente effettua il login, accade quanto segue: - > client invia nome utente - > risposta del server con "salt" - > il client genera un nonce casuale - > client invia "bcrypt (nonce + bcrypt (sale + password) + tempo) + + tempo + nonce" - > server verifica che il nonce non sia stato utilizzato negli ultimi 5 minuti, quindi verifica la password. È fatto confrontando l'input inviato dal client con "bcrypt (nonce + dbvalue + time)". - > per gli utenti non esistenti, viene inviato un sale di miele.

È piuttosto difficile hackerare, ma richiede il lato client Javascript per i browser.

Anche se si ha un effetto collaterale, l'hash di bcrypt viene sottoposto a hashing ogni volta con nuovo nonce e tempo.

Questa risposta è effettivamente facile da sbagliare, quindi ho creato un diagramma:

Inoltre,guardaquiperchéaggiungoquestostratoaggiuntivoancheconSSL: link