hashing della password su frontend o backend? [duplicare]

@John ha già descritto molto bene il passaggio della password sulla rete (usa HTTPS).

Per rispondere alla tua domanda:

Where should I hash them? Frontend or Backend?

Il back-end . Se le hai solo cancellate nel frontend, sei vulnerabile a un attacco hash.

La ragione per cui hai hash le password nel tuo database è di impedire a un utente malintenzionato che ha già compromesso il tuo database di utilizzare tali password.

Se hai hash le password nel back-end, un utente malintenzionato deve prima craccarle per utilizzarle sul tuo sito web. ma se li si hash nel frontend, un attacker non ha bisogno di farlo, può solo passare l'hash così come è memorizzato nel database.

L'hashing del frontend protegge la porzione di utenti che riutilizzano le password su siti Web diversi da quelli che vengono compromessi, quindi è una buona aggiunta all'hash back-back, ma non è un'alternativa ad esso (non è nemmeno un'alternativa su HTTPS; se il certificato è scaduto, è necessario rinnovarlo, l'hashing di frontend non ti aiuterà qui.

Stai confondendo due cose: sicurezza del trasporto e sicurezza del database. HTTPS che utilizza TLS protegge solo il trasporto dei dati dal client al server. Ciò significa che un intercettatore non sa quale client e server si stanno inviando reciprocamente (semplificato). La memorizzazione delle password è un argomento completamente diverso. Vuoi assicurarti che, anche se un utente malintenzionato accede al tuo database, non può accedere alle password in chiaro.

Indipendentemente dal modo in cui memorizzi le password, dovresti sempre utilizzare TLS. In caso contrario, un intercettatore può registrare ciò che il client invia al server per l'autenticazione. Quindi non importa se esegui la password HASHING sul lato client o sul lato server. L'utente malintenzionato potrebbe semplicemente registrare ciò che va sul filo e riprodurre la comunicazione per ottenere l'accesso, impersonando il client.

(Si noti che si desidera fare la password HASHING, non la crittografia. L'hashing è a senso unico, la crittografia no)

L'hashing dovrebbe essere fatto al back-end. Il back-end è sotto il tuo controllo, quindi puoi far rispettare l'hashing che sta avvenendo come dovrebbe. Inoltre è possibile avere un hashing sul lato client. Non si dovrebbe utilizzare l'hashing lato client da solo, come ad esempio il processo essere fatto in JavaScript che l'utente potrebbe bloccare o manipolare. Potrebbe non sembrare una minaccia ragionevole, ma non dovresti mai fidarti di nessun dato fornito dall'utente. Pertanto non dovresti assumere che il client stia facendo l'hashing correttamente. Questo implica che devi assolutamente farlo nel back-end.

HTTPS fornisce sicurezza solo per il livello di trasporto. Non ha nulla a che fare con i meccanismi di sicurezza necessari per lo storage.

Non dovresti criptare le password. Dovresti eseguirne l'hash, quindi non puoi decrittografarli in seguito (né a un utente malintenzionato).

E il passo hash è sempre fatto sul backend, dal momento che farlo sul lato client consentirebbe a un utente malintenzionato di accedere ai propri hash un metodo per accedere su ogni account.

HTTPS (HTTP su TLS / SSL) fornisce sicurezza sui dati in transito / dati in movimento NON fornisce crittografia sui dati a riposo (Database, File su un disco rigido) - > Crittografato con AES, 3DES, BlowFish, ecc.

È possibile fornire la crittografia sul database, ma non l'intero database in quanto ciò mangerà le risorse (i file crittografati sono più grandi di quelli non crittografati). Basta crittografare un campo specifico, ad esempio PII cliente - > Informazioni sulla carta di credito.

Non è una buona pratica crittografare le password degli utenti, basta HASH e SALE.

Quando scadrà il tuo certificato HTTPS, è giusto che l'utente malintenzionato possa annusare le password in testo normale, basta fornire il livello di sicurezza sul tuo codice.

Quando l'utente fornisce la password, il codice dovrebbe avere una stored procedure (SQL) che corrisponda al valore HASHED + SALT della password dell'utente nel database. Se il valore di HASH + SALT non corrisponde, ovviamente è una password errata.

Nota: gli hash garantiscono l'integrità.

La funzione SALT attenuerà il rischio che l'attaccante esegua un attacco con tavolo arcobaleno, perché l'attaccante non conosce il valore SALT.

La chiave: HASH + SALT

link