Sicherheit, Kryptographie: Stupid Challenge - Response-Protokoll?

StackOverflow https://stackoverflow.com/questions/188043

Frage

Ok Jungs nur ein kleines Spiel:

Ich habe einige Spezifikationen für ein Projekt. Irgendwann stellen sie für die folgenden ein Passwort über das Netz zu verschlüsseln, zu sagen, dass es ein Challenge-Response-Protokoll ist: 

CLIENT ----------------------------- SERVER

(1)ask for challenge -------------->

(2)    <---------------------------- send SHA1 taken from the time
                                       (this is the challenge)
(3) make SHA1 xor PASSWORD --------> if it's equal to SHA1 xor stored password

(4)    <---------------------------- Grant access

Für diejenigen, die nicht wissen, es SHA steht für Secure Hashing Algorithm, ein Standard-Algorithmus für die Kryptographie.

Ich hoffe, es ist klar. Frage: Wenn ich Pakete schnuppern 2 und 3 (die „Herausforderung“ und die „Herausforderung xor Passwort“, habe ich das tatsächliche Kennwort nur mit einem anderen xor zwischen ihnen beide Es gibt andere Art und Weise, diese Art von Protokoll zu implementieren!?!? ??

War es hilfreich?

Lösung

Wie wäre es folgende Möglichkeiten:

  1. Server sendet eine zufällige Herausforderung
  2. Client sendet SHA1-Prüfsumme (challenge + Passwort)
  3. Server vergleicht gegen SHA1-Prüfsumme (challenge + gespeicherte Passwort)

Andere Tipps

würden Sie in der Lage sein, um das Passwort Reverse Engineering. Sie möchten die SHA des Passworts schicken, nicht das Passwort selbst. Ihre eigenen Sicherheitsprotokolle Roll ist so gut wie nie eine gute Idee. Können Sie nicht SSL oder etwas Gleichwertiges verwenden?

http://en.wikipedia.org/wiki/Cryptographic_nonce

Das ist ein ziemlich schreckliches Protokoll. Wenn dies möchte, dass Sie etwas, das jemand implementieren, weigern sich. Es gibt bestehende, überprüft Protokolle für diese Art der Sache. Wenn dies ist ein Spiel, in dem Sie alle Fehler hinweisen -. In Ordnung

  • Wer hört die Schritte 2 & 3 kennt das Passwort
  • Jeder, den Schritt 3 und stellt die Zeit hört kann das Passwort Brute-Force, wenn er eine Vorstellung von der Genauigkeit der Zeit auf dem Server hat
  • kann ich so tun, als ein Server (arp-Vergiftung, dns rediction, usw.) zu sein, und Ihr Passwort erhalten, nie Schritt 4 abgeschlossen und ein Timeout
    • Vortäuschen
  • Vulnerable zu Mann in der Mitte Angriffen, weil es kein gemeinsames Geheimnis zwischen Client / Server oder Zertifikaten auf dem Server
  • Stützt sich auf dem Server die SHA1 (Zeit) und wartet auf eine Antwort zu speichern, so kann ich den Server mit Anfragen für Herausforderungen überlasten und nie antworten kann.

Und ich bin fehlt auf jeden Fall ein paar mehr.

Sie haben Recht - wenn Sie die Herausforderung an und (challenge XOR Passwort) erfassen dann das Passwort zu extrahieren ist einfach

.

Sie müssen in Schritt 3 die richtige Verschlüsselung verwenden, nicht XOR. Verschlüsseln Sie die Herausforderung mit dem Passwort.

Um ein Angreifer das Leben erschweren Sie zufällige Daten hinzufügen könnte, was Sie verschlüsseln zu: z encrypt paddingCHALLENGEpadding. Der Server kümmert sich nicht darum, was die Polsterung ist, weiß er, wo die Herausforderung suchen, aber es bedeutet, ein Angreifer nicht wissen, was der ganze Klartext ist.

Wie die anderen haben darauf hingewiesen, sind Sie richtig. Denken Sie auch daran, dass jemand Kommunikation abfangen konnte (3) und es möglicherweise erneut, während die reale Benutzer-Netzwerk Probleme auftreten (zB: ein DDOS), würde der Betrüger dann in und oft angemeldet sein, das ist ausreichend, um das Passwort zu ändern (dh , viele Systeme nicht erforderlich, dass Sie ein Kennwort angeben inorder es zu ändern, wenn Sie angemeldet sind).

Sie möchten HMAC (verkeilt-Hash Message Authentication Code) zu berücksichtigen. Ich habe hier ausführlich darüber gebloggt: http://blog.ciscavate.org/2007/09/creating-a-secure-webauth-system-part-1-hmac.html und ich werde eine kurze Zusammenfassung unten geben.

HMAC ist ein Verfahren, um sicherzustellen, dass eine Nachricht von jemandem mit Zugang zu einem gemeinsamen geheimen Schlüssel generiert wurde. HMAC macht Gebrauch von irgendeiner Art von Einweg-Hash-Funktion (wie MD5 oder SHA-1), das Geheimnis zusammen mit einer Nachricht zu verschlüsseln. Dies erzeugt eine kurze Digest von 16-20 Bytes, die als Fingerabdruck der Nachricht + geheimen Kombination wirkt. Wenn der Digest zusammen mit der Nachricht gesendet wird, kann der Empfänger (unser server) den Hash mit der gleichen HMAC Berechnung neu erzeugen und die lokal vergleichen, mit der Digest-Digest erzeugt, der mit der Nachricht kam. Denken Sie daran: der Server das Geheimnis zu hat, so hat es genügend Informationen, um die digest zu bestätigen. (Dies berücksichtigt nur das Problem der Herkunft einer Nachricht zu überprüfen, aber Sie können den gleichen Ansatz verwenden, um die gesamte Nachricht zu verschlüsseln, wenn Sie ein anderes Geheimnis verwenden, sagen eine Reihe von öffentlichen Schlüsseln.)

So wie ich dies tun würde, ist die folgende:

  1. Herausforderung des Servers.

  2. Server antwortet mit ihrer öffentlichen Schlüssel ist (Für, sagen die RSA-Verschlüsselung) digital unterzeichnet.

  3. Client prüft PK, und verschlüsselt Kennwort mit dem Schlüssel, dann digital signiert die verschlüsselten Kennwort ein.

  4. Server überprüft Signatur und entschlüsselt das Passwort speichern / überprüfen Sie es.

Die digitale Signatur ist hier wichtig, da es als der Beginn wirkt den Menschen in den Middle-Angriffen zu verhindern.

Wie andere haben darauf hingewiesen, ja, das ist ein schlechter Challenge-Response-Algorithmus.

Sie wollen wahrscheinlich Digest Authentication , verwendet, wie von HTTP. In der Tat, wenn Ihr Protokoll über HTTP ist, können Sie Ihre eigenen und einfach zu verwenden, oder diese implementieren überspringen zu schreiben.

Public-Key-Verschlüsselung? Verwenden Sie den öffentlichen Schlüssel des Servers, um das Passwort zu verschlüsseln.

Obwohl es nie eine gute Lösung ist, Ihr eigenes kryptographisches Protokoll ausrollen, und es ist etwas, würde ich nicht vorschlagen ....

Um das Problem zu überwinden, die Sie konfrontiert sind ... F - Eine Funktion, die monoton steigenden Wert im Passwort und ein Pseudo-Zufall nimmt und gibt eine Zahl zurück. Für z.B. Hash (Hash (Passwort) ^ Timestamp)

  1. Server: Fordern Sie Herausforderung, Senden (Timestamp). Denken Sie daran, Last Timestamp gesendet.
  2. Client, sendet Response (Senden F (Passwort, Timestamp) und Zeitstempel)
  3. Server. Aktivieren Sie Client unter Verwendung von Hash (Passwort) und Zeitstempel vom Client gesendet (> Zeitstempel in Herausforderung gesendet)
  4. Wenn Kunde korrekt ist, Zugriff gewähren.
  5. Stellen Sie sicher, vorhanden Zeitstempel ist größer als alle Client-Zeitstempel vor dem nächsten Herausforderung gesendet Replay-Attacken zu verhindern.

Mit freundlichen Grüßen, Ashish Sharma

ich glaube, der Diffie-Hellman ist ein bekanntes und festes Schlüsselaustauschprotokoll?

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top