La crittografia delle password è necessaria per un sito Web HTTPS? [duplicare]

Crittografare la password prima di inviarla tramite HTTPS probabilmente non aggiunge più sicurezza.

Considerare: come viene crittografata la password dal mittente e come viene decrittografata dal destinatario?
Se si utilizza un algoritmo simmetrico, come hanno negoziato la chiave? Se la chiave è incorporata nel client, chiunque eseguirà il reverse engineering del client avrà accesso ad esso.
Se si utilizza un algoritmo asimmetrico (cioè a chiave pubblica), per crittografare la chiave o per negoziare una chiave per un algoritmo simmetrico ... si sta solo facendo lo stesso che SSL / TLS sta facendo per voi.

Utilizza semplicemente la versione più alta disponibile di TLS, con la chiave più lunga disponibile sia per il server che per i client.

Solo per completezza: HTTPS utilizza SSL / TLS. Originariamente stava per "HTTP su SSL". Oggi SSL è stato trovato vulnerabile e dovresti usare il suo successore TLS.

Sul server, fai un hash di (password + valore salt). Esistono molte informazioni su come eseguire l'autenticazione sicura basata sul Web nella Guida definitiva all'autenticazione del sito Web basata su modulo di Stack Overflow. .

La generalizzazione di Frederics risponde un po ', potrebbe esserci la necessità di crittografare la password sul client se la soluzione non utilizza HTTPS end-to-end nel flusso di dati delle credenziali.

Alcuni motivi per non utilizzare HTTPS end-to-end sono:

• L'HTTPS viene terminato su un server periferico come un bilanciamento del carico o un proxy inverso, con un semplice HTTP tra il server periferico e il server di destinazione finale (la situazione di Frederics sarebbe un altro esempio di questo).
• Le richieste vengono mantenute a riposo a un certo punto del loro flusso, ad esempio in una coda di messaggi per il livellamento del carico

In questo caso, potrebbe avere senso utilizzare la crittografia a livello di messaggio come descritto.

Ho visto richieste del genere da parte dei clienti che hanno venduto il concetto di crittografia end-to-end per le password.

L'installazione è la seguente: esiste un server dedicato che convalida le password e altre credenziali e nient'altro. Il server che ospita l'applicazione delega l'autenticazione a quel server dedicato, passando le credenziali crittografate.

La crittografia HTTPS si interrompe sul server delle applicazioni, ma le credenziali crittografate sono ancora protette finché non raggiungono il server di autenticazione.

Ora non sono sicuro che abbia molto senso, ma come ho detto ho incontrato clienti che richiedono una cosa del genere.

In genere un'architettura software è costituita da un frontend, un middleware (per la business logic) e un backend (ad es. database) e tutti questi componenti elaborano la password. Un utente malintenzionato che ha compromesso uno di questi componenti sarebbe in grado di intercettare le password.

Una soluzione è criptare le password. Con la crittografia a chiave pubblica sarebbe possibile il seguente scenario:

• il backend crea una chiave pubblica e privata
• la chiave pubblica verrà inclusa nel modulo in cui l'utente inserisce la sua password
• quando l'utente invia il modulo un codice JavaScript crittografa la password utilizzando la chiave pubblica
• il frontend riceve la password crittografata, la invia al middleware che la invia al back-end
• solo il backend può decrittografarlo

Pertanto, un utente malintenzionato che ha compromesso il frontend o il middleware non può vedere la password in chiaro.