Qual è il modo migliore per trasmettere l'hash della password su TLS inaffidabile?

Dovresti esaminare Blocco dei certificati .

In questo modo è possibile fidarsi del proprio certificato autofirmato e del certificato del server solo dal proprio client mediante una ricerca approfondita della chiave pubblica del certificato. Quindi la catena di autorità non viene seguita (che è dove un certificato autofirmato cade) e invece la chiave pubblica viene convalidata dall'applicazione client per essere attendibile direttamente.

Non dovresti guardare l'hashing, o qualsiasi altra cosa sul livello dell'applicazione in quanto sarà intrinsecamente suscettibile a un attacco MITM.

Non puoi.

Non esiste un modo sicuro per trasmetterlo se non è possibile autenticare il server e stabilire un canale sicuro. Se non è possibile autenticare il server, non si può essere sicuri se si sta parlando con il server o l'autore dell'attacco. Quindi, anche se utilizzi TLS per stabilire un canale sicuro, non ti protegge affatto dal momento che potresti parlare con l'utente malintenzionato mentre pensi che stai parlando al server.

Il certificato è essenziale. Senza di esso, o una certa conoscenza della chiave pubblica del server, non puoi essere sicuro di comunicare realmente al server in quanto un utente malintenzionato potrebbe agire come un uomo nel mezzo tra te e il server.

TLS usa Diffie-Hellman per lo scambio di chiavi. Se osservate la sezione sicurezza della pagina di Wikipedia, troverete il seguente attacco che è esattamente ciò a cui sei vulnerabile.

In the original description, the Diffie–Hellman exchange by itself does not provide authentication of the communicating parties and is thus vulnerable to a man-in-the-middle attack. Mallory may establish two distinct key exchanges, one with Alice and the other with Bob, effectively masquerading as Alice to Bob, and vice versa, allowing her to decrypt, then re-encrypt, the messages passed between them.

Conclusione

Devi avere un certificato valido per essere in grado di autenticare il server o sarai vulnerabile all'uomo nell'attacco centrale. Un modo semplice per ottenere ciò è includere il certificato del server nella tua applicazione, noto anche come blocco dei certificati .

Raggruppare il certificato CA radice auto-creato con l'applicazione e configurarlo per rifiutare tutti i certificati non attendibili. Se si utilizza solo il proprio certificato CA, questo è probabilmente più sicuro che affidarsi alle normali CA, dal momento che le CA sono state compromesse in passato dagli aggressori e sono anche soggette alle autorità governative e alla politica.

Il rollare il tuo schema di autenticazione è sconsiderato, ed è quasi garantito essere meno sicuro del semplice utilizzo di TLS con un certificato in bundle.

Poiché altri hanno già menzionato l'autenticazione TLS e cosa si può fare per quel problema, mi concentrerò su:

What is the best way to transmit password hash?

MITM è una delle minacce nel tuo scenario. Un'altra possibile minaccia (anche molto comune) è una violazione dei dati. devi considerare il caso in cui il tuo database potrebbe essere compromesso e deve prendere le necessarie precauzioni anche sul lato server. L'hashing delle password sul lato client non è una buona idea, a meno che non ci si fidi del server con le password e si sta eseguendo nuovamente l'hashing sul server. Immagino che non sia il caso del tuo scenario perché il server è tuo.

Se gli hash delle password, inviati dai client, vengono memorizzati così come sono nel database, un utente malintenzionato può impersonare tutti gli utenti inviando al server le password con hashing dal database così com'è. In questo caso, le password Hashed fungeranno semplicemente da token di accesso segreto . Leggi questo per ulteriori dettagli.

And what hashing algorithm should I use?

Alcune buone funzioni di hashing (per memorizzare le password sul server) includono bcrypt, scrypt e PBKDF2. Dai un'occhiata alla risposta di Thomas Pornin per il motivo per cui sono migliori. Fondamentalmente, queste funzioni, se usate correttamente, renderanno molto più difficile il compito di un utente malintenzionato in caso di violazione dei dati.

Utilizza SRP ( S ecure R emote P meccanismo di TLS.

Il client e il server si autenticano a vicenda in base alla conoscenza di una password condivisa che non viene mai inviata (ciò significa che qualunque cosa si usi come password -in questo caso l'hash- dovrà essere memorizzato in chiaro dal server).