Sie können nicht.

Um Informationen sicher über einen unsicheren Kanal zu senden, benötigen Sie eine Verschlüsselung.

Die symmetrische Verschlüsselung ist deaktiviert, da Sie zuerst den Schlüssel transportieren müssten, was Sie nicht sicher über einen unsicheren Kanal [*] tun können.

Damit erhalten Sie einen öffentlichen Schlüssel Kryptographie. Sie könnten natürlich Ihre eigenen rollen, aber Sie möchten nicht ein Dave sein, also ist das raus, was Sie mit HTTPS belässt.

_{[*] Sie können natürlich versuchen, einen sicheren Kanal zum Austauschen des Schlüssels zu verwenden, beispielsweise den physischen Austausch eines Schlüssels. Dann können Sie Krypto mit geheimem Schlüssel wie Kerberos verwenden. Sub>}

TLS ist wirklich die einzige Möglichkeit, dies zu tun.

Aber was ist, wenn ich es mit JavaScript verschlüssle?

Der Angreifer kann das von Ihnen verwendete JavaScript ändern Senden Sie sie an den Client oder fügen Sie einfach ein eigenes JavaScript ein, das alle eingegebenen Informationen protokolliert.

Dann verwende ich CSP und SRI, um das Hinzufügen von Skripten und das Ändern meiner eigenen Skripte zu verhindern.

Ich bin froh, dass Sie moderne Tools zum Schutz Ihrer Website verwenden, aber SRI in einem nicht sicheren Kontext schützt wirklich nur vor dem Kompromiss einer externen Ressource. Ein Angreifer kann einfach die CSP-Header und SRI-Tags ändern.

Es gibt wirklich keine Möglichkeit, dies ohne die Verwendung von Verschlüsselung von Anfang an zu tun, und die einzige Standardmethode hierfür ist die Verwendung von TLS.

Ich bin damit einverstanden, dass Sie HTTPS verwenden sollten, aber Sie können es noch sicherer machen, indem Sie den Salted Challenge Response-Authentifizierungsmechanismus (SCRAM, siehe RFC 5802) für den tatsächlichen Authentifizierungsaustausch verwenden.

Die Implementierung ist nicht trivial, aber das Wesentliche ist, dass Sie, anstatt das Kennwort an den Server zu senden, dem Server den Nachweis senden, dass Sie das Kennwort kennen. Da das Ableiten des Beweises eine Nonce vom Client und Server verwendet, kann sie von einem Angreifer nicht wiederverwendet werden (wie das Senden des Hashs selbst).

Dies hat einige zusätzliche Vorteile bei der Verwendung von HTTPS mit Die von Ihnen beschriebene grundlegende Authentifizierung:

1. Der Server sieht Ihr Kennwort beim Anmelden nie. Wenn es jemandem gelungen ist, schädlichen Code auf dem Server einzufügen, weiß er immer noch nicht, wie Ihr Kennwort lautet
2. Wenn in der HTTPS-Implementierung ein Fehler vorliegt (denken Sie an Heartbleed), können Angreifer Ihr Kennwort immer noch nicht abrufen. Da das Kennwort auch nach Umgehung von TLS nicht verfügbar ist.
3. Wenn Sie aus irgendeinem Grund kein HTTPS verwenden können, ist dies besser, als das Kennwort im Klartext zu senden. Ein Angreifer kann Ihr Passwort aufgrund des Austauschs nicht erraten. Sie sollten jedoch weiterhin HTTPS verwenden, da die Tiefenverteidigung besser ist.
ol>

Bitte beachten Sie , dass dies nur dann sicher ist, wenn der Client das SCRAM ausführen kann Berechnungen ohne Code vom Server herunterzuladen. Sie können einen fetten Client bereitstellen, oder Benutzer können möglicherweise ihren eigenen Code schreiben, den sie steuern. Das Herunterladen des SCRAM-Codes über HTTP bietet einem Angreifer die Möglichkeit, den SCRAM-Code so zu ändern, dass das Kennwort im Klartext gesendet oder auf andere Weise verfügbar gemacht wird.

In diesem Fall sollten Sie auf jeden Fall TLS bereitstellen.

Wenn Sie versuchen, ein Transportsicherheitssystem über HTTP zu erfinden, werden Sie letztendlich ohnehin einen Susbset der TLS-Funktionalität implementieren. Beim Entwerfen und Implementieren eines solchen Systems sind viele Fallstricke zu beachten, die noch verstärkt werden, wenn Sie versuchen, das System in einer Sprache zu implementieren, die nicht viele Sicherheitsfunktionen bietet.

Auch wenn Sie haben eine korrekte Implementierung eines kryptografischen Protokolls in JavaScript implementiert (was bereits eine große Herausforderung darstellt). Sie können sich nicht darauf verlassen, dass diese Implementierung gegen Timing-Angriffe resistent ist, und das Ganze bricht ab, wenn jemand Skripte deaktiviert hat (z. B. mit NoScript).

In der Regel sollten Sie die Implementierung auswählen, die aus den einfachsten, verständlichsten und vertrauenswürdigsten Komponenten besteht, für die Sie die geringste Menge an sicherheitskritischem Code schreiben müssen. Um Andrew Tannenbaum zu zitieren:

Eine erhebliche Anzahl der Probleme (bei der Anwendungssicherheit) wird durch fehlerhafte Software verursacht, die auftritt, weil Anbieter immer mehr Funktionen hinzufügen ihre Programme, was zwangsläufig mehr Code und damit mehr Fehler bedeutet.

Muss ich einen Verschlüsselungsalgorithmus wie die Verschlüsselung mit öffentlichem RSA-Schlüssel implementieren?

Wenn Sie dies in Erwägung ziehen, können Sie auch die ganze Meile gehen und verwenden HTTPS. Da Sie kein Experte zu sein scheinen, führt das "Rollen Ihrer eigenen" Verschlüsselung zweifellos zu Fehlimplementierungen, die es unsicher machen.

Es ist tatsächlich durchaus möglich.

Das Passwort muss auf der Clientseite gehasht werden, jedoch nicht mit einer statischen Funktion. Die folgende Methode verwendet zwei Schritte und ist von der Digest-Zugriffsauthentifizierung inspiriert:

HINWEIS: Der Server verwaltet eine HMAC mit dem Kennwort und dem entsprechenden Kennwort Schlüssel ( Digest );

1. Der Client fordert zunächst eine Nonce an den Server an, der Server gibt den Schlüssel zurück strong> und der Nonce ;
2. Client berechnet: HMAC (HMAC ( Passwort , Schlüssel ), Nonce ) und sendet es an den Server;
3. Server berechnet: HMAC ( Digest , Nonce ) und vergleicht es mit dem empfangenen Wert.
ol>

Dies schützt Sie vor Wiederholungen.

Das Hauptinteresse, das ich sehe, ist kein Schutz vor Abhören, aber um ganz sicher zu sein, dass das Klartext-Passwort nicht gespeichert wird der Server, nicht einmal in einem Systemprotokoll (siehe Twitter oder GitHub).

Hinweis: HMAC kann durch PBKDF2 ersetzt werden.

Es gibt tatsächlich eine Möglichkeit, einen Benutzer über eine unsichere Verbindung zu authentifizieren: SRP-Protokoll (Secure Remote Password). SRP wurde speziell entwickelt, um es einem Client zu ermöglichen, sich bei einem Server zu authentifizieren, ohne dass ein Man-in-the-Middle-Angreifer das Kennwort des Clients erfassen oder sogar die Authentifizierung wiedergeben kann, um sich später als Client auszugeben, unabhängig davon, ob die Authentifizierung erfolgreich war oder nicht. Darüber hinaus wird durch eine erfolgreiche Authentifizierung mit SRP ein gemeinsamer geheimer Schlüssel erstellt, den sowohl der Client als auch der Server kennen, ein MitM jedoch nicht. Dieser geheime Schlüssel kann für symmetrische Verschlüsselung und / oder HMACs verwendet werden.

Es gibt jedoch eine Reihe von Einschränkungen von SRP:

1. Der Benutzer muss sich in einem sicheren Bereich registriert haben Auf diese Weise muss für den Registrierungsprozess passwortäquivalentes Material übertragen werden (obwohl der Server es nicht speichern muss).
2. Obwohl es sicher ist, eine SRP-Anmeldung mit einem nicht vertrauenswürdigen Server zu versuchen (d. h Ihr Passwort wird diesem Server nicht zugänglich gemacht, und Sie können feststellen, dass der Server Ihr Passwort nicht in seiner Datenbank hatte. Es ist nicht sicher, eine Anmeldewebseite von einem nicht vertrauenswürdigen Server zu laden (es könnte gesendet werden Eine Seite, die jeden Tastendruck erfasst und irgendwohin sendet.
3. Obwohl eine erfolgreiche Authentifizierung über SRP einen sicheren gemeinsamen geheimen Schlüssel generiert, muss der Code für die tatsächliche Verwendung dieses Schlüssels in einer Web-App geladen werden Ein Server und ein Angreifer können diesen Code manipulieren, um den symmetrischen Schlüssel zu stehlen und Änderungen an den Anforderungen und Antworten vorzunehmen.
ol>

Mit anderen Worten, während SRP in Situationen nützlich sein kann, in denen Sie einen vertrauenswürdigen Client haben, der seinen Code nicht über die unsichere Verbindung herunterladen muss, und Sie auch eine andere sichere Möglichkeit haben, die Benutzer zu registrieren, SRP ist nicht für eine Webanwendung geeignet. Web-Apps laden ihren Code immer vom Server herunter. Wenn die Verbindung zum Server nicht sicher ist, kann ein MitM (oder ein anderer Netzwerkangreifer, z. B. jemand, der DNS fälscht) schädlichen Code in die Web-App einfügen, und Sie haben nichts zu tun. das Opfer kann dagegen tun. Sobald dieser Code vorhanden ist, kann er jedes von Ihnen eingegebene Passwort oder andere Daten erfassen, jeden generierten Schlüssel stehlen und alle Anfragen oder Antworten, die Sie erhalten, manipulieren, ohne dass Sie es überhaupt wissen.

Es ist sicherlich möglich, ein Passwort sicher über HTTP zu senden. Es gibt sogar einen Standard dafür. Es heißt HTTP-Digest und ist in RFC 7616 definiert. Es ist seit einiger Zeit Teil der HTTP-Spezifikation. Es wurde ursprünglich entwickelt, um nur den MD5-Message-Digest-Algorithmus ("Hashing") zu verwenden. Spätere Überarbeitungen des Standards ermöglichen es dem Client und dem Server jedoch, den zu verwendenden Algorithmus auszuhandeln.

Leider gibt es viele Probleme mit HTTP-Digest und das auffälligste davon ist, dass der Server das Passwort im Klartext haben muss. Während es möglich ist, Kennwörter sicher über HTTP zu kommunizieren, ist es nicht möglich, Kennwörter während der Verwendung sicher auf dem Server zu speichern. Im Grunde ist es also nicht nützlich.

Wie andere gesagt haben, ist es besser, TLS zu implementieren, da es mehrere Probleme gleichzeitig löst und ziemlich vorwärtskompatibel ist.

Wie andere gesagt haben TLS! TLS! TLS! (und mit anständiger Schlüssellänge auch)

Wenn Sie jedoch HTTP und einen Server zur Implementierung verwenden müssen, ist dies für den programmatischen oder menschlichen Gebrauch? Wenn für den menschlichen Gebrauch, suchen Sie nach einer grundlegenden Authentifizierung oder formularbasiert? Und können Ihre Verwendungen ein wenig Logik anwenden, z. Nicht für Joe Public. Muss noch etwas geschützt werden oder nur das Passwort selbst?

Wenn ja, können Sie sich Folgendes ansehen:

• Verwenden Sie a Einmal-Passwort-Pad / Generator (RSA-Anhänger sind nicht billig, und wenn Sie so viel Geld ausgeben müssen, können Sie sich TLS leisten)
• Eine andere 2-Faktor-Authentifizierung wie SMS (nicht) ohne eigene Probleme).
• Ein einfacher Herausforderungs- / Antwortmechanismus zum Verschleiern des Kennworts, z. B. zeigt die Seite zwei Zahlen im Text an (auch nicht offensichtlich gekennzeichnet). Der Benutzer muss das Kennwort mit a beginnen einfache Berechnung wie Differenz zwischen den beiden Zahlen, die zu jeder Ziffer einer PIN hinzugefügt werden, möglicherweise mit zufälligen Dingen vor und / oder nach, z. B. 98634572dkkgdld. Das Ändern der Herausforderungsnummern sollte Wiederholungsangriffe stoppen, die nicht sofort versucht werden. Wenn ein Angreifer jedoch genügend Versuche erfassen kann, kann er dies möglicherweise herausfinden. Sie können auch keine Verschleierungslogik in ein benutzerbezogenes Skript einfügen, da dies angezeigt wird. Wenn das Schema zu komplex ist, werden Ihre Benutzer Sie noch mehr hassen.

Ich würde Trotzdem sind Zertifikate mit TLS heutzutage billig (sogar kostenlos), so dass verschlungene Verschleierungsschemata wirklich keinen Grund mehr haben, zu existieren.