Frage:
Wie sichere ich Passwörter über HTTP?
FireCubez
2018-11-09 19:57:16 UTC
view on stackexchange narkive permalink

Angenommen, mein Passwort lautet abc . Ich möchte es über HTTP an den Server senden.

Ich könnte es im Klartext senden und den Server es hashen lassen und es mit den Einträgen in seiner Datenbank vergleichen, aber dann jeder, der Datenverkehr über diese Verbindung sehen kann würde das Passwort im Klartext sehen.

Dann könnte ich es clientseitig hashen und den Server es einfach ohne Hashing vergleichen lassen, da es bereits gehasht ist (oder der Server könnte sogar den Hash verdoppeln, aber keinen Unterschied in diese Situation). Andererseits würde jeder, der den Datenverkehr sehen kann, das Passwort-Hash sehen und dann das Hash-Passwort an den Server senden und der Server würde es akzeptieren.

Wie sende ich Passwörter über HTTP? Muss ich einen Verschlüsselungsalgorithmus wie die RSA-Verschlüsselung mit öffentlichem Schlüssel implementieren? Oder ist dies unmöglich?

Die Methode sollte in jedem Browser verwendbar sein.

Warum können Sie nicht einfach TLS verwenden?Es gibt wirklich keinen anderen Weg, dies sicher zu tun.
@AndrolGenhald Ich könnte, das ist nur ein Proof of Concept.Wenn es keinen anderen Weg gibt, dies sicher zu tun, dann ist das die Antwort, nach der ich gesucht habe.Sie sollten es als Antwort posten
Sie benötigen kein natives TLS - Sie könnten TLS theoretisch über HTTP implementieren -, aber es wäre bei weitem nicht praktisch.
@AndrolGenhald Es gibt keinen guten Grund, TLS nicht zu verwenden, aber ich glaube, es gibt viele andere Möglichkeiten, dies sicher zu tun.Zum Beispiel könnte man http durch ssh tunneln.
Versuchen Sie vielleicht, mit ECDHE die Schlüssel sicher auszutauschen?
@emory Im Poster wurde klargestellt, dass der Kontext die Kommunikation zwischen Webbrowser und HTTP-Server ist und nicht die benutzerdefinierte Anwendung zwischen benutzerdefinierten Servern.
Ist dies ein echtes Problem oder nur ein Gedankenexperiment?
@whatsisname Ich habe in einem früheren Kommentar festgestellt, dass es sich nur um ein Experiment handelt
Ich hasse es zwar, wenn Sie A fragen und die Leute antworten "benutze nur B", aber ich muss den vielen Antworten "benutze nur TLS" zustimmen, da dies der einfachste Weg für ein praktisches Problem ist.Jetzt haben Sie angegeben, dass es sich nicht um ein praktisches Problem handelt, sondern "nur zum Experimentieren". Vielleicht möchten Sie sich über [Zero-Knowledge-Protokolle] (https://en.wikipedia.org/wiki/Zero-knowledge_proof) informieren, die was tunSie wollen.
Die ursprüngliche Implementierung des MSN Messenger-Kennworts war für dieses Szenario geeignet.Der Server hat Ihnen ein "Salt" gesendet und Sie haben Ihr Passwort damit gehasht und den Hash zurück an den Server gesendet.Da der Server Ihr Passwort kannte, konnte er dieselbe Berechnung durchführen.Der Server war dafür verantwortlich, dass keine Salze wiederverwendet wurden
FWIW, selbst wenn Sie es schaffen, die Passwörter sicher zu übertragen, haben Sie nichts erreicht.Der Rest der Sitzung ist unverschlüsselt und kann leicht gestohlen oder geändert werden.Selbst wenn Sie sicher beweisen können, dass Sie Bob sind, kann Alice in dem Moment, in dem dies geschieht, Ihre Sitzung stehlen und so lange Bob sein, wie sie möchte.
@curiousguy Wenn OP `ssh -L 127.0.0.1:8080:intra.example.com:80 gw.example.com` ausführte und dann zu http://127.0.0.1:8080 navigierte, wird die Verbindung verschlüsselt und die Passwörter gesichert.(1) Dies setzt voraus, dass OP in gw.example.com ssh kann und (2) der Webserver möglicherweise nicht auf lokale Anfragen reagiert.Dieses Beispiel funktioniert möglicherweise nicht für OP, aber die Behauptung, dass TLS der einzige Weg ist, ist falsch.
@emory Ist das nicht _in Effekt_ mit TLS, sondern nur mit "ssh", anstatt es direkt im Client zu implementieren?Und wäre die Verbindung von `gw.example.com` zum echten Webserver nicht immer noch anfällig für Abhören?
@TripeHound Ich würde empfehlen, nur TLS zu verwenden und sich nicht um diese Probleme zu kümmern.Wenn es jedoch tatsächlich TLS verwendet, aber ssh es tun lässt, anstatt es direkt im Client zu implementieren, ist die Verbindung zum realen Webserver nicht anfällig für Abhören.
Neun antworten:
#1
+113
tim
2018-11-09 20:08:48 UTC
view on stackexchange narkive permalink

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>

Könnten Sie es nicht zweimal hashen?Einmal auf der Client-Seite, einmal auf dem Server?
@NathanMerrill - [Durch das Hashing des Passworts auf der Clientseite wird der Hash nur zum Passwort] (https://security.stackexchange.com/questions/8596/https-security-should-password-be-hashed-server-side-or-or-clientseitig) (ohne ein Schema, das zusätzliche Informationen enthält).Es ist jedoch wertlos, nur das Passwort zu sichern - Sie müssen mindestens den ** Kanal ** authentifizieren, oder ein Angreifer kann sich als beide Konversationsende ausgeben, auch ohne das Passwort zu kennen.
Das ist irreführend.Ja, du kannst.In dieser Frage wird gefragt, wie Kennwörter gesichert werden sollen, wenn Sie kein HTTP verwenden können.Eine schlechte Unternehmensrichtlinie und eine falsch konfigurierte Firewall können die Verwendung von HTTP erzwingen.In solchen Situationen ist der Austausch von Zertifikaten (IPsec TLS SCRAM usw.) über einen Seitenkanal möglich und sollte die Antwort sein.Beantworten Sie die Frage, anstatt Ratschläge zu geben, die nicht gesucht wurden.
@noɥʇʎԀʎzɐɹƆ Ich habe erwähnt, dass es Alternativen gibt, wenn ein sicherer Seitenkanal verwendet werden kann (was für die in anderen Antworten genannten Alternativen erforderlich ist).Aber darum geht es bei der Frage nicht wirklich ("Die Methode sollte in jedem Browser verwendbar sein").Es gibt definitiv Anwendungsfälle für diese Alternativen, aber "Wir können HTTPS nicht verwenden, weil unsere Infrastruktur zu kaputt ist" sollte keiner von ihnen sein.
Ich stimme dem Hauptpunkt zu - es geht nicht.Aber ich würde hinzufügen, dass es nicht helfen würde, selbst wenn Sie Dave sind und Ihre eigene Krypto rollen.Der Code, der die Krypto ausführt, wird über HTTP bereitgestellt und kann daher manipuliert werden.
#2
+45
AndrolGenhald
2018-11-09 20:09:53 UTC
view on stackexchange narkive permalink

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.

#3
+25
Melanie
2018-11-10 00:01:01 UTC
view on stackexchange narkive permalink

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.
  4. 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.

Sie können dies sicher mit einem Fat Client (einem Desktop oder einer mobilen Anwendung) tun, der auf sichere Weise verteilt wird.Bei einem In-Browser-Thin-Client wird der Client-Code selbst jedoch auch über HTTP bereitgestellt. Wie @AndrolGenhald hervorhob, können Angreifer in der Mitte ihn abfangen und ändern, um das Kennwort an sie zu senden.
@Zoltan Das stimmt sehr, danke für die Klarstellung.Die ursprüngliche Frage gibt nicht an, ob sie einen dünnen oder einen fetten Kunden benötigen, daher würde meine Antwort nicht in allen Fällen zutreffen.Aber auch über HTTP bietet dies meiner Meinung nach zusätzliche Sicherheit.Der Angriff hat sich vom bloßen Schnüffeln des Datenverkehrs zum Ändern des Codes entwickelt.Nichts Unüberwindbares, also wäre es nicht sicher, aber vielleicht weniger schlimm?Und ich denke, sowohl HTTPS als auch SCRAM zu haben, ist sehr vorteilhaft.
Wenn Sie damit einverstanden sind, können Sie diese Einschränkung in Ihrer Antwort erwähnen.Ansonsten gefällt mir Ihre Antwort sehr gut, da die Herausforderung auch mein erster Gedanke war und keine der anderen Antworten dies erwähnte.
Vielen Dank, ich habe meine Antwort aktualisiert.Lassen Sie mich wissen, wenn Sie der Meinung sind, dass weitere Klarstellungen erforderlich sind!
Sieht gut aus für mich, danke, positiv bewertet.Sie sollten jedoch den Teil "Dank an Zoltan" entfernen, da Höflichkeitssätze wie Begrüßung, Unterschrift und Dankeschön in Fragen und Antworten auf Stack Exchange-Websites nicht empfohlen werden, um sich auf den Inhalt zu konzentrieren.Oh, und übrigens willkommen bei Stack Exchange!:) :)
@Melanie Sie haben absolut Recht, dass es auch mit nur HTTP besser ist.Es gibt Angreifer, die nur zu passiven Angriffen fähig sind.Abgesehen davon gibt es heutzutage keinen Grund, HTTPS nicht zu verwenden, wenn es kostenlos ist.
Erfordert SCRAM, dass das Kennwort auf dem Server abrufbar gespeichert werden muss?Oder kann es noch gesalzen + gehackt werden
@IanF1 Der Server muss nur einen Hash des Passworts kennen.Außerdem implementieren alle mir bekannten Browser einen ähnlichen Mechanismus: [HTTP Digest Authentication] (https://en.wikipedia.org/wiki/Digest_access_authentication), sodass diese Methode auch mit einem Thin Client verwendet werden kann.Auf der anderen Seite basiert der HTTP-Digest auf den veralteten MD5-Hashes, aber ich bin mir nicht sicher, wie unsicher dies ist (MD5 ist nicht für jede Anwendung fehlerhaft).
@Zoltan, Ich habe das Dankeschön entfernt.Obwohl ich es nicht mag, keine Kredite zu geben, wo sie fällig sind, denke ich, dass sie hier in den Kommentaren stehen.Danke noch einmal!
@Jost Die Verwendung von MD5 (oder einer Funktion, die auf der Iteration von MD5 oder der Zusammensetzung mit einem Salz oder einem Nounce basiert) zum Speichern oder Überprüfen von Passwörtern ist heute nicht mehr kaputt als jemals zuvor:t vereinfacht werden und MD5 ^ 1000 benötigt immer noch 1000 Iterationen der Berechnung, und es gibt keinen besseren Weg, um herauszufinden, welches x MD5 ^ 1000 (x) = y erfüllt, als verschiedene Werte von x oder Methoden zu versuchen, die auf vorberechneten Listen basierenauch die beste Methode für SHA1 oder modernere Hash-Funktionen.Hier wurden keine theoretischen oder praktischen Fortschritte erzielt.
#4
+7
Polynomial
2018-11-10 00:31:25 UTC
view on stackexchange narkive permalink

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.

#5
+6
Brian Williams
2018-11-09 22:03:34 UTC
view on stackexchange narkive permalink

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.

#6
+2
Pierre del Perugia
2018-11-10 15:38:45 UTC
view on stackexchange narkive permalink

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.
  4. 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.

Dann kann ein Angreifer Code einfügen, um das Passwort direkt von der zu erhalten.Eine verrückte Idee: "Leider ist es * nur ein bisschen * schwierig, HTTPS für reservierte IP-Adressen zu unterstützen. Bitte [führen Sie diesen Code auf Ihrem Terminal aus] (https://stackoverflow.com/a/7285256) und fügen Sie das Ergebnis der HMAC ein. "(Deaktivieren Sie natürlich das Einfügen von Kopien, um Pastejacking auf lange Sicht zu verhindern.)
#7
+2
CBHacking
2018-11-10 16:42:21 UTC
view on stackexchange narkive permalink

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.
  4. 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.

#8
+2
Christopher Schultz
2018-11-11 04:51:56 UTC
view on stackexchange narkive permalink

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.

#9
+1
Richard N
2018-11-13 03:55:03 UTC
view on stackexchange narkive permalink

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.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...