Frage zu hashalgorithmen(md5, sh1, etc.)


  • Mod

    PHPNewbie schrieb:

    Hmmm, ok. Nehmen wir an der Public key sei im Clienten drin, der Man in the middle könnte den Clienten abfischen bevor er zum Anwender kommt und somit den public key manipulieren/ersetzen -> Also gleiche Problem wie als wenn der Server direkt den public key schickt.

    So ist es.



  • Ok, hab jetzt auch das symmetrische Verfahren implementiert.
    D.h. ich hole mir erst den PublicKey vom server, generiere einen symmetrischen schlüssel beim Client und schicke diesen dann verschlüsselt mit dem PublicKey zum server.

    Zur Man in the middle Problematik:

    [quote=SeppJ]Denn eigentlich müssten sich die beiden Kommunikationspartner dafür zuvor irgendwo persönlich getroffen haben und Geheimnisse (Zertifikate) ausgetauscht haben. [/quote]

    Genau das halte ich für meine Anwendung einfach für unlösbar. Wie soll ich das bitte machen? Irgendwann muss der Client runtergeladen werden und die Quelle muss vertrauenswürdig sein. Da es sich aber um eine Flash .swf Datei handelt die auf vielen verschiedenen Webseiten eingebunden werden soll(wie ein Video eben) geht das einfach nicht.

    Da stelle ich mir auch gleich die Frage, ob der Browser den ich nutzte nicht auch schon aus einer Quelle stammt die nicht vertrauenswürdig ist und somit schon Kompromittiert ist und die Zertifikatliste die er enthält nutzlos ist.

    Wie soll ich das Lösen?


  • Mod

    PHPNewbie schrieb:

    Da stelle ich mir auch gleich die Frage, ob der Browser den ich nutzte nicht auch schon aus einer Quelle stammt die nicht vertrauenswürdig ist und somit schon Kompromittiert ist und die Zertifikatliste die er enthält nutzlos ist.

    Wie soll ich das Lösen?

    Gar nicht. Das CA-System ist nicht gut, aber es ist wohl, worauf du dich in der Praxis einlassen müsstest.



  • PHPNewbie schrieb:

    D.h. ich hole mir erst den PublicKey vom server, generiere einen symmetrischen schlüssel beim Client und schicke diesen dann verschlüsselt mit dem PublicKey zum server.

    Das ist nicht sicher gegen Replay-Angriffe, btw.



  • Nicht? Wenn ich mein gehashtes Passwort mit dem symmetrischen schlüssel versehe und dann verschicke, dann bringt der replay Angriff doch nichts mehr, weil bei der nächsten Session ja wieder ein anderer symmetrischer Schlüssel verwendet wird, entspricht das nicht schon der "Nonce"?


  • Mod

    PHPNewbie schrieb:

    Nicht? Wenn ich mein gehashtes Passwort mit dem symmetrischen schlüssel versehe und dann verschicke, dann bringt der replay Angriff doch nichts mehr, weil bei der nächsten Session ja wieder ein anderer symmetrischer Schlüssel verwendet wird, entspricht das nicht schon der "Nonce"?

    Was hindert denn den Angreifer, die exakt gleichen Schritte zu wiederholen? Für den Server sieht das so aus, als wäre der Schlüssel eben beide Male der gleiche.



  • Ok, ich habe jetzt noch die nonce gegen Replay-Angriffe implementiert. Bin mir aber nicht sicher ob ich alles richtig gemacht habe. Ich liste mal meine schritte auf:

    1.) Client: requestPublicKey();
    2.) Server: Session starten, Keypaar erzeugen, private key merken, public key zurücksenden
    3.) Client: Public key erhalten, symmetrischen schlüssel generieren, symmetrsichen Schlüssel mit erhaltenem public key verschlüsseln und abschicken.
    4.) Server: symmterischen Schlüssel aus Nachricht mittles privaten key extrahieren, nonce generieren, nonce mit symmetrischen schlüssel verschlüsseln und abschicken.
    5.) Client: nonce extrahieren, cnonce generieren, passwort hashen. nonce, cnonce, username und hashedPasswort konkatenieren und das ergebnis hashen. cnonce, username, hashedPasswort und hashedPasswordWithNonce verschlüsseln und abschicken.
    6.) Server: daten entschlüsseln und hashedPasswordWithNonce verifizieren, dann hashedPassword mit datenbank abgleichen. User ggf. auf eingeloggt setzen, nonce löschen.

    Jetzt müsste ich noch an geeigneter stelle prüfen ob der User schon eingeloggt ist, am besten vor 1.)? Hmm, zudem Speicher ich den Login status im Moment nur in der $_SESSION, sollte besser in die Datenbank oder?

    Ich weis ist viel Text, wäre aber schön wenn Jemand das kurz prüfen kann und mir Verbesserungsvorschläge/Korrekturen gibt.

    Das was bisher von euch gekommen ist war schon super! Danke!


  • Mod

    Wenn du tatsächlich jedes Mal wieder einen neues Schlüsselpaar auf dem Server erzeugen möchtest, dann kann das auch als Nonce dienen, und dein vorheriges Vorhaben macht mehr Sinn. Aber wie identifiziert der Client dann den Server? Und wie lange braucht das Erzeugen der Schlüsselpaare?



  • SeppJ schrieb:

    Aber wie identifiziert der Client dann den Server?

    Im moment wohl gar nicht. Der Client schluckt einfach die Daten die nach einer von ihm gesendeten Anfrage kommen(prüft natürlich ob die Daten das richtige Format haben etc.). Bin ehrlich gesagt auch damit(zertifikte etc.) überfordert. Eigentlich sollte der Client nur anfragen an den richtigen Server senden können und auch nur von diesem erhalten. Das Szenario das sich jemand dazwischen klinkt(oder gar den Clienten so manipuliert, dass dieser an den falschen Server sendet) und meinen Server "simuliert" fange ich nicht ab.

    SeppJ schrieb:

    Und wie lange braucht das Erzeugen der Schlüsselpaare?

    Ich verwende openssl_pkey_new zum erzeugen der Schlüsselpaare, weis nicht wie lange das dauert, der ganze Prozess von 1.) - 6.) dauert vielleicht eine halbe Sekunde.


Anmelden zum Antworten