Das kannst du nicht.

Es gibt keine sichere Möglichkeit, es zu übertragen, wenn Sie den Server nicht authentifizieren und keinen sicheren Kanal einrichten können. Wenn Sie den Server nicht authentifizieren können, können Sie nicht sicher sein, ob Sie mit dem Server oder dem Angreifer sprechen. Selbst wenn Sie TLS verwenden, um einen sicheren Kanal einzurichten, schützt es Sie überhaupt nicht, da Sie möglicherweise mit dem Angreifer sprechen, während Sie denken, dass Sie mit dem Server sprechen.

Das Zertifikat ist unerlässlich . Ohne diesen oder einige Kenntnisse des öffentlichen Schlüssels des Servers können Sie nicht sicher sein, dass Sie wirklich mit dem Server kommunizieren, da ein Angreifer als Mann in der Mitte zwischen Ihnen und dem Server fungieren könnte.

TLS verwendet Diffie-Hellman für den Schlüsselaustausch. Wenn Sie sich den Abschnitt Sicherheit auf der Wikipedia-Seite ansehen, finden Sie den folgenden Angriff, für den Sie genau anfällig sind.

In der ursprünglichen Beschreibung ist der Diffie –Hellman-Austausch allein bietet keine Authentifizierung der kommunizierenden Parteien und ist daher anfällig für einen Man-in-the-Middle-Angriff. Mallory kann zwei unterschiedliche Schlüsselaustausche einrichten, einen mit Alice und einen mit Bob, die sich effektiv als Alice für Bob tarnen, und umgekehrt, sodass sie die zwischen ihnen übertragenen Nachrichten entschlüsseln und dann erneut verschlüsseln kann.

Fazit

Sie benötigen ein gültiges Zertifikat, um den Server authentifizieren zu können. Andernfalls sind Sie im mittleren Angriff für Menschen anfällig. Eine einfache Möglichkeit, dies zu erreichen, besteht darin, das Serverzertifikat in Ihre Anwendung aufzunehmen, das auch als Anheften von Zertifikaten bezeichnet wird.

Sie sollten sich mit Anheften von Zertifikaten befassen.

Auf diese Weise können Sie Ihrem selbstsignierten Zertifikat und diesem Serverzertifikat nur von Ihrem Client durch eine gründliche Suche von vertrauen der öffentliche Schlüssel des Zertifikats. Daher wird die Autoritätskette nicht befolgt (wo ein selbstsigniertes Zertifikat herunterfällt), sondern der öffentliche Schlüssel wird von der Clientanwendung als direkt vertrauenswürdig validiert.

Sie sollten sich nicht mit Hashing befassen. oder irgendetwas anderes auf der Anwendungsschicht, da es von Natur aus anfällig für einen MITM-Angriff ist.

Bündeln Sie Ihr selbst erstelltes Stammzertifizierungsstellenzertifikat mit Ihrer Anwendung und konfigurieren Sie es so, dass alle nicht vertrauenswürdigen Zertifikate abgelehnt werden. Wenn Sie nur Ihr eigenes CA-Zertifikat verwenden, ist dies wahrscheinlich sicherer als das Verlassen auf die normalen CAs, da CAs in der Vergangenheit von Angreifern kompromittiert wurden und auch Regierungsbehörden und der Politik unterliegen.

Das Rolling Ihres eigenen Authentifizierungsschemas ist tollkühn und garantiert weniger sicher als die einfache Verwendung von TLS mit einem gebündelten Zertifikat.

Da andere bereits über die TLS-Authentifizierung gesprochen haben und was in Bezug auf dieses Problem getan werden kann, werde ich mich nur auf Folgendes konzentrieren:

Was ist der beste Weg, um Passwort-Hash zu übertragen?

MITM ist eine der Bedrohungen in Ihrem Szenario. Eine weitere mögliche (auch sehr häufige) Bedrohung ist eine Datenverletzung. Sie müssen den Fall berücksichtigen, in dem Ihre Datenbank möglicherweise gefährdet ist, und müssen auch auf der Serverseite die erforderlichen Vorsichtsmaßnahmen treffen. Das Hashing von Passwörtern auf der Clientseite ist keine sehr gute Idee, es sei denn, Sie vertrauen dem Server Ihre Passwörter nicht an und Sie haschen sie erneut auf dem Server. Ich denke, dass dies bei Ihrem Szenario nicht der Fall ist, da der Server Ihr eigener ist.

Wenn die von den Clients gesendeten Kennwort-Hashes unverändert in der Datenbank gespeichert werden, kann sich ein Angreifer als alle Benutzer ausgeben, indem er dem Server die gehashten Kennwörter unverändert aus der Datenbank sendet. Hashed Passwörter dienen in diesem Fall lediglich als geheime Zugriffstoken . Lesen Sie dies für weitere Details.

Und welchen Hashing-Algorithmus sollte ich verwenden?

Einige gute Hashing-Funktionen (zum Speichern von Passwörtern) auf dem Server) umfassen bcrypt, scrypt und PBKDF2. Schauen Sie sich Thomas Pornins großartige Antwort an, warum diese besser sind. Grundsätzlich erschweren diese Funktionen bei ordnungsgemäßer Verwendung die Aufgabe eines Angreifers im Falle einer Datenverletzung erheblich.

Verwenden Sie den SRP -Mechanismus ( S ecure R emote P assword) von TLS.

Der Client und der Server authentifizieren sich gegenseitig basierend auf der Kenntnis eines freigegebenen Kennworts, das niemals gesendet wird (dies bedeutet, dass alles, was Sie als Kennwort verwenden - in diesem Fall der Hash - vom Server im Klartext gespeichert werden muss).