SHA1 Verschlüsselung: Verständnisfrage

[norbert =:-)]

Hallo, liebe Forumianer!

Ich beschäftige mich für ein Projekt gerade mit dem Verschlüsseln von Zugangsdaten. Dazu möchte ich statt "Benutzername + Passwort + Hostname" einfach den zugehörigen Hash-Wert zur Kontrolle an den Server übermitteln.

Ich habe mich zwar mit den diversen Hash-Algorithmen beschäftigt (und mich deshalb für SHA1 entschieden) - in die mathematischen Tiefen bin ich aber noch nicht vorgedrungen.

Soweit ich die Sache aber verstanden habe, ist jeder Hash-Wert einzigartig - und wäre somit für meinen Zweck geeignet. Da der Wert aber endlich ist, kann ich irgendwie nicht glauben, dass es einen Hashwert tatsächlich nur 1x geben kann.

Daher meine Frage: Kann es theoretisch sein, dass für unterschiedliche "Benutzername + Passwort + Hostname"-Kombinationen irgendwann mal der gleiche Hash-Wert erzeugt wird?

Ich hoffe, ich habe mich einigermaßen verständlich ausgedrückt und Danke euch schon mal im voraus.

lg
norbert =:-)

[Sven Rautenberg]

Moin!

Daher meine Frage: Kann es theoretisch sein, dass für unterschiedliche "Benutzername + Passwort + Hostname"-Kombinationen irgendwann mal der gleiche Hash-Wert erzeugt wird?

Ja, nicht nur theoretisch, sondern auch praktisch.

Das Resultat von SHA1 (und jedem anderen SHA-Algorithmus, sowie MD4, MD5 und Konsorten) kann man auffassen als eine Zahl mit ziemlich vielen, aber definiert begrenzten Stellen. Daraus folgt, dass der Algorithmus nur endlich viele Ergebnisse haben kann - aber unendlich viele Eingabewerte. Folglich gibt es sogenannte Kollisionen, bei denen zwei unterschiedliche Eingabewerte zum gleichen Ausgabewert führen.

Es ist nur nicht so leicht, solche Kollisionen absichtlich zu finden. Angenommen, ein String mit zehn Zeichen führt zu einem bestimmten SHA1-Ergebnis, dann kann ein damit kollidierender Wert vielleicht ein String mit tausend Zeichen sein. Das kann aber niemand herausfinden, ohne alle Strings mit tausend Zeichen mal durchprobiert zu haben - das ist ziemlich zeitaufwendig.

Aber ein ganz anderer Aspekt ist mir viel wichtiger:

Ich beschäftige mich für ein Projekt gerade mit dem Verschlüsseln von Zugangsdaten. Dazu möchte ich statt "Benutzername + Passwort + Hostname" einfach den zugehörigen Hash-Wert zur Kontrolle an den Server übermitteln.

Du willst also die Sicherheit erhöhen. Wie? Ein Javascript einzusetzen, welches aus den drei Informationen Username, Passwort und Hostname ein SHA1 errechnet, welches dann an den Server gesendet wird, wird dir keinerlei Zusatzsicherheit bieten, weil der böse Angreifer dann auch direkt irgendeinen hoffentlich passenden SHA1-String generieren und dir senden kann. Oder (und das ist bei unverschlüsselter Kommunikation ja auch immer möglich) er fängt den gültigen generierten SHA1-String ab und kriegt mit dem dann kompletten Zugriff, ohne sich um Usernamen etc. kümmern zu müssen.

Sicherheit erhälst du bei Logins nur durch Verschlüsselung, beispielsweise mit SSL. Alles andere ist Spielkram, macht das Verfahren komplizierter, fehleranfälliger, benutzerunfreundlicher, aber kein bißchen sicherer.

- Sven Rautenberg

[norbert =:-)]

Hallo Sven!

Vielen Dank für Deine Antwort - hat erheblich zum Verständnis beigetragen!

Du willst also die Sicherheit erhöhen. Wie? Ein Javascript einzusetzen ...

Ich habe absichtlich "Projekt" geschrieben, da es nur entfernt mit HTML zu tun hat. Daher auch nicht JavaScript - das versuche ich grundsätzlich tunlichst zu vermeiden :-)

Aber mit Sicherheit liegst Du schon richtig. Und dass ich gerade bei "komplizierter, fehleranfälliger, benutzerunfreundlicher" angelangt bin, stimmt auch.

Im Prinzip mache ich mir gerade Gedanken, einen Benutzer an einem Server zu authentifizieren. Grundsätzlich bastle ich also die Sessions von Php nach - nur dass die Session-Id jedesmal anders sein soll, weil mir eine statische Session-Id zu anfällig erscheint.

Der Server schickt bei jeder Antwort eine (jedesmal andere zufällige) Session-Id für den Benutzer mit. Der Benutzer verschlüsselt mit seinem Passwort bei der nächsten Antwort die Id - der Server entschlüsselt diese wieder und kontrolliert, ob es sich dabei um die zuletzt gesandte Id handelt. In der Antwort schickt er dann wieder eine neue Id mit. usw.

Ich muss dazu sagen, dass es sich beim "Benutzer" nicht um einen Browser handelt (daher die Möglichkeiten dieser Spielereien) - der Server ist allerdings ein Webserver.

Das Prinzip scheint für mich OK - das Handling eher nicht so, da ich dafür jedesmal die Session-Daten des Benutzers aus einer DB auslesen und auch neu setzen muss. Bei tausenden Benutzern kommt da schon für das Session-Handling allerhand zusammen :-(

lg

norbert =:-)

[wahsaga]

hi,

Das Prinzip scheint für mich OK - das Handling eher nicht so, da ich dafür jedesmal die Session-Daten des Benutzers aus einer DB auslesen und auch neu setzen muss.

Warum ist das ein "Muss"?
Weil sich die Session-ID jedes mal ändert, und damit eine Identifikation einer Sessiondatei über diesen Wert nicht mehr möglich ist?

Dann identifiziere sie doch anders - durch einen zusätzlichen, hinreichend eindeutigen Schlüssel, der neben deiner ständig erneuerten Session-ID ebenfalls noch übergeben wird.

gruß,
wahsaga

[norbert =:-)]

Hallo wahsaga!

Du meinst, das ganze auf Fileebene auszulagern?

lg

norbert =:-)

[wahsaga]

hi,

Du meinst, das ganze auf Fileebene auszulagern?

Ich hatte dich so verstanden, dass du es als Nachteil deines Vorhabens ansiehst, die Daten nicht wie im Session-Mechanismus von PHP "üblich" in Dateien ablegen zu können, sondern zur Datenbank gezwungen wirst - und das sehe ich nicht so.

Ob's sinnvoll ist - da habe ich auch Bedenken, Svens Hinweise bzgl. verchlüsselter Übertragung sind da angebracht.

gruß,
wahsaga

[Sven Rautenberg]

Moin!

Im Prinzip mache ich mir gerade Gedanken, einen Benutzer an einem Server zu authentifizieren. Grundsätzlich bastle ich also die Sessions von Php nach - nur dass die Session-Id jedesmal anders sein soll, weil mir eine statische Session-Id zu anfällig erscheint.

Warum? Benutzername und Passwort sind auch statisch - wer das kennt, kommt rein, egal ob er erwünscht oder unerwünscht ist. Und irgendwann einmal MUSS diese Information zum Server gesendet werden.

Eine Session-ID ersetzt nun für eine gewisse Zeit die Info "Username+Passwort", das bedeutet: Man tauscht den einen String (wenn man Username und Passwort einfach mal zusammensetzt, ergibt sich daraus eine Zeichenkette, die "stimmen" muß, um Zugang zu erlangen) durch einen anderen String (der für eine gewisse Zeit Synonym für Username und Passwort wird) - an einer Tatsache aber ändert sich nichts: Wenn man dem Server als Angreifer den richtigen String schickt, wird dieser Informationen rausrücken.

Der Server schickt bei jeder Antwort eine (jedesmal andere zufällige) Session-Id für den Benutzer mit. Der Benutzer verschlüsselt mit seinem Passwort bei der nächsten Antwort die Id - der Server entschlüsselt diese wieder und kontrolliert, ob es sich dabei um die zuletzt gesandte Id handelt. In der Antwort schickt er dann wieder eine neue Id mit. usw.

Das hilft dir alles nichts, wenn du unverschlüsselt arbeitest. Denn wenn du unverschlüsselt arbeitest, kann man die legitime Kommunikation immer noch mitlesen, muß also gar nicht selbst aktiv werden. Oder man baut dein komplexes Machwerk nach, bzw. erhält irgendwie Zugang zu deinem Client - und schon bricht dein ganzes schönes Konstrukt zusammen.

Glaube mir: Es bringt dir nichts, den Sessionmechanismus bzw. dessen ID-Wechsel zu manipulieren. Wenn dir die MD5-IDs (128 Bit) nicht gefallen, weil sie dir angeblich zu kurz sind, dann verwende einfach längere. SHA-1 bietet sich an (160 Bit), alternativ SHA-256, SHA-384 oder SHA-512 (jeweils soviele Bits, wie in der Nummer angegeben).

Das Prinzip scheint für mich OK - das Handling eher nicht so, da ich dafür jedesmal die Session-Daten des Benutzers aus einer DB auslesen und auch neu setzen muss. Bei tausenden Benutzern kommt da schon für das Session-Handling allerhand zusammen :-(

Das Prinzip ist auch Müll. Wenn du Sicherheit haben willst, verwende SSL. Dann kann keiner die Kommunikation abhören.

Und gegen die bösen Buben, die dann eben per SSL mit deinem Server kommunizieren, verwendest du vernünftige Passworte.

Der Session-Mechanismus ist jedenfalls nicht dein Problem.

- Sven Rautenberg

[norbert =:-)]

Hallo Sven!

Es freut mich, einen kritischen Ansprechpartner zu haben. Aber ...

Warum? Benutzername und Passwort sind auch statisch - wer das kennt, kommt rein

Da ist klar. Ich gehe mal davon aus, dass Benutzer ihre Passwörter nicht mit einem PostIt am Bildschirm hinterlassen. Mir geht es eher um alle anderen Fälle.

Wenn man dem Server als Angreifer den richtigen String schickt, wird dieser Informationen rausrücken.

Darum gehts mir. Sitzt ein Böser zwischen Client und Server, kann er entweder die aktuelle verschlüsselte Session-Id abfangen und sogar an den Server weiterschicken. Er erhält dann auch eine Antwort - kann aber mit der neue Session-Id nix anfangen, da er ja nicht weiß, wie diese korrekt zu verschlüsseln wäre.

Das hilft dir alles nichts, wenn du unverschlüsselt arbeitest.

Das ist die leichteste Übung - ich brauch ja nur https zu verwenden. Ich möchte aber die ganze Logik möglichst sicher haben, bevor ich das ganze auch noch verschlüssle.

Aber die Frage mal andersrum: Kann ich mir den ganzen Schmarrn sparen, wenn ich NUR https verwende und einfach in jedem Request Benutzername und Passwort mitschicke?

lg

norbert =:-)

[Sven Rautenberg]

Moin!

Es freut mich, einen kritischen Ansprechpartner zu haben. Aber ...

Warum? Benutzername und Passwort sind auch statisch - wer das kennt, kommt rein

Da ist klar. Ich gehe mal davon aus, dass Benutzer ihre Passwörter nicht mit einem PostIt am Bildschirm hinterlassen. Mir geht es eher um alle anderen Fälle.

Dass der Benutzer diese Angaben auch "abgreifbar" für Menschen notieren könnte, das ist in meiner Betrachtung irrelevant.

Dein Server muß, damit es überhaupt zu einer gültigen Session (ob nun mit oder ohne wechselnde Session-ID) kommt, irgendwo und irgendwann diese zwei Informationen erhalten.

Ein Angreifer kann dorthin ebenfalls beliebig viele Usernamen und Passworte als Einbruchsversuch hinschicken. Weil diese Informationen statisch sind, erhält er mit Glück, oder nach genügend langer Zeit mit Rumprobieren, irgendwann korrekte Strings.

Das bedeutet: Du sorgst dich darum, dass jemand deine existierenden Sessions angreifen kann (dazu muß der Angreifer auch erstmal die Session-ID richtig raten!), sorgst dich aber nicht um Username und Passwort - wobei doch gerade Passworte, die der Benutzer selbst setzen kann, oft die größte Sicherheitslücke bilden.

Wenn man dem Server als Angreifer den richtigen String schickt, wird dieser Informationen rausrücken.

Darum gehts mir. Sitzt ein Böser zwischen Client und Server, kann er entweder die aktuelle verschlüsselte Session-Id abfangen und sogar an den Server weiterschicken. Er erhält dann auch eine Antwort - kann aber mit der neue Session-Id nix anfangen, da er ja nicht weiß, wie diese korrekt zu verschlüsseln wäre.

Wenn er wirklich zwischen Client und Server sitzt, dann liest er einfach nur mit. Die korrekten wechselnden Session-IDs werden vom Client produziert.

Alternativ bildet er gegenüber dem Client einen Server, und gegenüber deinem Server einen Client. Er reicht deine Serversession-ID zum Client durch, nimmt dessen Berechnung entgegen und gibt sie wieder deinem Server. Und alles wird funktionieren.

Das hilft dir alles nichts, wenn du unverschlüsselt arbeitest.

Das ist die leichteste Übung - ich brauch ja nur https zu verwenden. Ich möchte aber die ganze Logik möglichst sicher haben, bevor ich das ganze auch noch verschlüssle.

Aber die Frage mal andersrum: Kann ich mir den ganzen Schmarrn sparen, wenn ich NUR https verwende und einfach in jedem Request Benutzername und Passwort mitschicke?

Du kannst dir den ganzen Schmarrn sparen - so oder so. SSL bringt dir Verschlüsselung und damit Sicherheit gegen Abhören des Datentransfers.

Rechne doch mal selbst hoch, wie wahrscheinlich es ist, dass jemand die Standard-Session-ID mit 128 Bit "errät".

Angenommen, man könnte als Angreifer in jeder Sekunde eine Milliarde Session-IDs prüfen. Und angenommen, es würden zu diesem Zeitpunkt tatsächlich eine Milliarde Session-IDs von Nutzern aktiv sein.

Das bedeutet:
2^128 = 3.4e+38 mögliche IDs
        1e+9 gleichzeitig aktive IDs
Statistisch ist also jede 3.4e+29ste Session-ID aktiv.

Um 3.4e+29 Session-IDs zu prüfen, mit 1e+9 IDs pro Sekunde, sind 3.4e+20 Sekunden notwendig oder 1.1e+13 Jahre. Durchschnittlich ist man nach der Hälfte der Zeit fertig: 5.5e+12 Jahre. Das ist immer noch hundertmal länger, als unser Universum alt ist (1.34e+10 Jahre).

Mit Pech (auf deiner Seite) dauert die Suche genau eine Sekunde, weil gleich die erste Session-ID gefunden wird. Dann ist aber wahrscheinlich, dass jemand die Kommunikation belauschen konnte. Deswegen ja SSL.

- Sven Rautenberg

[wahsaga]

hi,

Im Prinzip mache ich mir gerade Gedanken, einen Benutzer an einem Server zu authentifizieren. Grundsätzlich bastle ich also die Sessions von Php nach - nur dass die Session-Id jedesmal anders sein soll, weil mir eine statische Session-Id zu anfällig erscheint.

Kennst du eigentlich session_regenerate_id() ...?

gruß,
wahsaga

[norbert =:-)]

Jetzt hat mich aber jemand am falschen Fuss erwischt - das kannte ich tatsächlich noch nicht :-)

lg

norbert =:-)

[Daniel Thoma]

Hallo Sven,

Sicherheit erhälst du bei Logins nur durch Verschlüsselung, beispielsweise mit SSL. Alles andere ist Spielkram, macht das Verfahren komplizierter, fehleranfälliger, benutzerunfreundlicher, aber kein bißchen sicherer.

Diese Aussage ist nicht ganz richtig. Durch Verwendung einer Prüfsumme statt des Passwortes kann man durchaus mehr Sicherheit erreichen.
Wenn man das geschickt macht, kann man erreichen dass:

• Eine abgefangene Prüfsumme nicht für einen weiteren Zugriff verwendet werden kann
• Eine abgefangene Prüfsumme nicht für andere Dienste verwendet werden kann, die das selbe Verfahren verwenden (für andere natürlich sowieso nicht)

Das erreicht man, indem man eine Prüfsumme aus Passwort + id-des-Dienstes + id-des-Zugriffes erzeugt und nur diese verschickt.
Besser noch sollte man etwas wie summe(summe(Passwort + Name) + id-des-Dienstes + id-des-Zugriffes) verwenden. Damit muss auf dem Server nicht das Passwort sondern nur die Prüfsumme aus Passwort und Name gespeichert werden.

Ein bekanntes Verfahren, das genau so arbeitet und das Du vermutlich auch kennst, ist HTTP Digest Access Authentification

Es ist natürlich klar, dass ein solches Verfahren einen Dienst nicht vor "Man in the middle"-Angriffen schützt, aber sie sind dennoch eine Verbesserung.

Grüße

Daniel

[Sven Rautenberg]

Moin!

Sicherheit erhälst du bei Logins nur durch Verschlüsselung, beispielsweise mit SSL. Alles andere ist Spielkram, macht das Verfahren komplizierter, fehleranfälliger, benutzerunfreundlicher, aber kein bißchen sicherer.
Diese Aussage ist nicht ganz richtig. Durch Verwendung einer Prüfsumme statt des Passwortes kann man durchaus mehr Sicherheit erreichen.

Man verschleiert das Passwort, man verhindert aber nicht die Angriffsmöglichkeit durch eigene Loginversuche.

Ein bekanntes Verfahren, das genau so arbeitet und das Du vermutlich auch kennst, ist HTTP Digest Access Authentification

Digest-Authentifizierung versucht, ein Sicherheitsgefühl zu geben, welches durch die unverschlüsselte Datenübertragung der zu sichernden Daten nicht aufrecht erhalten werden kann.

Wer mitlauschen kann, wird so zwar nicht das Passwort des angegriffenen Accounts mitkriegen, aber alle abgefragten Daten. Nicht sehr beruhigend.

Und wer nicht mitlauschen kann, aber Username und Passwort rauskriegt, dem ist Digest oder SSL natürlich auch egal.

Deshalb: Entweder sind die Daten, die zu schützen sind, so wichtig, dass sie nur mit SSL rausgehen dürfen. Dann soll man SSL auch einsetzen, nichts anderes. Oder die Daten sind weniger wichtig und können ruhig abgehört werden. Dann muß man aber nicht versuchen, den Standard-Sessionmechanismus (von PHP) noch irgendwie zu "verbessern" - das bringt dann auch nichts mehr, ein Stehlen oder Erraten einer bestehenden Session ist extrem unwahrscheinlich.

Es ist natürlich klar, dass ein solches Verfahren einen Dienst nicht vor "Man in the middle"-Angriffen schützt, aber sie sind dennoch eine Verbesserung.

Der OP sprach von einer "Verbesserung" bei den Session-IDs, nicht von einer Verschleierung der Login-Daten.

Und ich halte beide Ansätze für mehr Sicherheit für nicht zielführend.

- Sven Rautenberg

[Daniel Thoma]

Hallo Sven,

Man verschleiert das Passwort, man verhindert aber nicht die Angriffsmöglichkeit durch eigene Loginversuche.

Man verschleiert das Passwort nicht nur, man schützt es effektiv. Es ist in der Praxis nunmal so, dass Menschen das gleiche Passwort für viele verschiedene Dienste verwenden. Aus diesem Grund kann das Passwort eine viel schützenswertere Information sein, als die übertragenen Daten. Desweiteren ist es gerade bei irgendwelchen Administrationoberflächen entscheidend eigene Zugriffe durchführen zu können, wärend die übertragenen Daten relativ uninteressant sind.
Das durchführen dieser Zugriffe ist aber mit einem solchen Verfahren nur durch "Man in the middle"-Angriff möglich und damit relativ aufwendig.

Der OP sprach von einer "Verbesserung" bei den Session-IDs, nicht von einer Verschleierung der Login-Daten.

Im wesentlichen ja, mir ging es allerdings nur um:

Ich beschäftige mich für ein Projekt gerade mit dem Verschlüsseln von Zugangsdaten. Dazu möchte ich statt "Benutzername + Passwort + Hostname" einfach den zugehörigen Hash-Wert zur Kontrolle an den Server übermitteln.

Darauf hast Du geantwortet, dass es zwischen Klartext und SSL nichts mehr Vernünftiges gäbe. Dieser Meinung bin ich nicht.
Digest Authentification schützt die Zugangsdaten effektiv und das halte ich wie oben ausgeführt durchaus für ein Gewinn an Sicherheit, wenn auch nicht unbedingt für den betreffenden Dienst selbst.

Grüße

Daniel

[Sven Rautenberg]

Moin!

Im wesentlichen ja, mir ging es allerdings nur um:

Ich beschäftige mich für ein Projekt gerade mit dem Verschlüsseln von Zugangsdaten. Dazu möchte ich statt "Benutzername + Passwort + Hostname" einfach den zugehörigen Hash-Wert zur Kontrolle an den Server übermitteln.
Darauf hast Du geantwortet, dass es zwischen Klartext und SSL nichts mehr Vernünftiges gäbe. Dieser Meinung bin ich nicht.
Digest Authentification schützt die Zugangsdaten effektiv und das halte ich wie oben ausgeführt durchaus für ein Gewinn an Sicherheit, wenn auch nicht unbedingt für den betreffenden Dienst selbst.

Ok, man muß (und das ist unzulässigerweise nicht geschehen) bei allen Sicherheitsbetrachtungen unterscheiden zwischen den möglichen Angriffsszenarien.

Eine Maßnahme, die konkret für ein Szenario den Sicherheitslevel hebt, kann sich zwar auf das Szenario bezogen positiv auswirken, insgesamt betrachtet aber dennoch recht wirkungslos verpuffen.

- Sven Rautenberg

[Bodo Thiesen]

Ich beschäftige mich für ein Projekt gerade mit dem Verschlüsseln von Zugangsdaten. Dazu möchte ich statt "Benutzername + Passwort + Hostname" einfach den zugehörigen Hash-Wert zur Kontrolle an den Server übermitteln.

Du willst also die Sicherheit erhöhen. Wie? [...]
Sicherheit erhälst du bei Logins nur durch Verschlüsselung, beispielsweise mit SSL. Alles andere ist Spielkram, macht das Verfahren komplizierter, fehleranfälliger, benutzerunfreundlicher, aber kein bißchen sicherer.

Quatsch. Schonmal von CHAP gehört?

Ich übermittele ein Formular mit:

form no-action (nur für Javascript)
text     name=user
password name=pass
hidden   name=callenge value=$RANDOM_TEXT

form action=...
 hidden response

button login onclick="calc_response+submit"

Im Javascrpit wird dann sha1 von user+pass+challenge berechnet und dann rausgesendet. Den challenge kennt der Server (er hatte ihn ja generiert und gesendet) und kann damit die angaben überprüfen. Um ihn zu unterstützen wird noch user mitgesendet. Der Server muß nun alle Challengesm, die er in der letzten Zeit (z.B. 5 Minuten) versendet hat mit dem passwort ausprobieren, um herauszufinden, ob das Passwort stimmt. Alternativ sendet man den challenge auch nochmal zurück, hier MUSS der Server dann aber auf jeden Fall überprüfen, ob er den Challenge
a) gerade selber generiert hatte und
b) ob er nicht vielleicht schonmal benutzt wurde, um sich einzuloggen.

Je nach dem, wie schützenswert die Daten sind, sollte man aber dennoch verschlüsseln, aber nicht weil die Login-Prozedur an sich unsicher ist, sondern weil der Übertragungskanal unsicher ist (nach dem Login kann jeder die Verbindung übernehmen, und selber Requests im Namen des eingeloggten Benutzers durchführen). Allerdings kann das nur jemand, der auch eine Crypto-Man-in-the-Middle-Attack durchführen kann, man steht dann also vor dem Problem des Key-Exchanges.

Gruß, Bodo

PS: Wenn man das Passwort auf dem Server nicht im Klartext gespeichert hat, sondern z.B. mit md5 gecrypted, erhöht das die Sicherheit in diesem Szenario eigentlich auch nicht mehr.

[Sven Rautenberg]

Moin!

Ich beschäftige mich für ein Projekt gerade mit dem Verschlüsseln von Zugangsdaten. Dazu möchte ich statt "Benutzername + Passwort + Hostname" einfach den zugehörigen Hash-Wert zur Kontrolle an den Server übermitteln.

Du willst also die Sicherheit erhöhen. Wie? [...]
Sicherheit erhälst du bei Logins nur durch Verschlüsselung, beispielsweise mit SSL. Alles andere ist Spielkram, macht das Verfahren komplizierter, fehleranfälliger, benutzerunfreundlicher, aber kein bißchen sicherer.

Quatsch. Schonmal von CHAP gehört?

Was hilft dir dein CHAP gegen einen Angriff, der einfach Usernamen und Passworte ausprobiert?

Das ist doch meine Argumentation: Was hilft es, das gesamte Konstrukt NACH dem Login kompliziert sicher zu machen (wobei es eine simple Methode dafür gibt, die SSL heißt), wenn aber das Login selbst nicht sicher ist.

Der Angriff auf vom Benutzer definierbare Passworte ist immer noch einer mit der höchsten Erfolgsquote.

Im Javascrpit wird dann sha1 von user+pass+challenge berechnet und dann rausgesendet. Den challenge kennt der Server (er hatte ihn ja generiert und gesendet) und kann damit die angaben überprüfen. Um ihn zu unterstützen wird noch user mitgesendet.

Und genau das kann ich, da dein Vorgehen bekannt ist, mit beliebigen generierten oder bekannten Usernamen und Passworten ebenfalls machen.

Dein CHAP erhöht also lediglich die Sicherheit beim Belauschen des Passwortes, nicht die Sicherheit gegen Einloggen. Und es enthält keinerlei Sicherheit gegen Mithören der Verbindung und Abgreifen der danach transferierten Dateninhalte.

PS: Wenn man das Passwort auf dem Server nicht im Klartext gespeichert hat, sondern z.B. mit md5 gecrypted, erhöht das die Sicherheit in diesem Szenario eigentlich auch nicht mehr.

Was die Datenübermittlung angeht, sicher nicht. Was die Datenspeicherung auf dem Server angeht, selbstverständlich.

Und es erfordert dann zusätzlich, dass das Passwort in deinem CHAP natürlich identisch behandelt wird.

Und zu irgendeinem Zeitpunkt muß zwangsläufig auch einmal ein unverschlüsseltes Passwort übermittelt werden: Wenn es geändert werden soll!

Ich bleibe dabei: Es ist unsinnig, sich komplizierte Session- oder Loginpasswortverschleierungsmechanismen auszudenken. Wenn man Sicherheit haben möchte, muß man auf Standards zurückgreifen, und die lauten: 1. SSL, 2. Sichere Benutzerpassworte. SSL schließt das Abhören von Passworten aus, und ordentliche Passworte verhindern den direkten Angriff durch Ausprobieren.

Deinen unfreundlichen Angriff mit "Quatsch" schiebe ich mal auf die unchristliche Uhrzeit, zu der man eigentlich keine gesalzenen Postings mehr verfassen sollte.

- Sven Rautenberg

[Bodo Thiesen]

Moin!

Sicherheit erhälst du bei Logins nur durch Verschlüsselung, [...]
Quatsch. Schonmal von CHAP gehört?

Was hilft dir dein CHAP gegen einen Angriff, der einfach Usernamen und Passworte ausprobiert?

Und was hilft deine Verschlüsselung dagegen?

Das ist doch meine Argumentation: Was hilft es, das gesamte Konstrukt NACH dem Login kompliziert sicher zu machen (wobei es eine simple Methode dafür gibt, die SSL heißt), wenn aber das Login selbst nicht sicher ist.

Das Login selbst ist bei CHAP genauso sicher, wie mit SSL. Den einzigen Vorwurf, den man bei CHAP machen kann, ist, daß alles NACH dem Login prinzipiell nicht sicher ist, dafür ist SSL beim Aufbau der Verbindung (also sogar noch vor dem Login) nicht sicher. Wie Du's drehst und wendest, absolut sicher bekommst Du das nicht ohne Key-Exchange.

Der Angriff auf vom Benutzer definierbare Passworte ist immer noch einer mit der höchsten Erfolgsquote.

Wer lässt den Benutzer schon Passwörter definieren ...

sha1 von user+pass+challenge

Und genau das kann ich, da dein Vorgehen bekannt ist, mit beliebigen generierten oder bekannten Usernamen und Passworten ebenfalls machen.

Und mit SSL kannst Du das nicht?

Dein CHAP erhöht also lediglich die Sicherheit beim Belauschen des Passwortes, nicht die Sicherheit gegen Einloggen. Und es enthält keinerlei Sicherheit gegen Mithören der Verbindung und Abgreifen der danach transferierten Dateninhalte.

SSL auch nicht, informiere Dich über "Man in the Middle" Attacken - es sind genau sie selben Voraussetzungen die man auch zum Mithören der unverschlüsselten Verbindung braucht. Immerhin schützt CHAP gegen das Mitlauschen des Passwortes, was SSL dann auch nicht mehr macht.

PS: Wenn man das Passwort auf dem Server nicht im Klartext gespeichert hat, sondern z.B. mit md5 gecrypted, erhöht das die Sicherheit in diesem Szenario eigentlich auch nicht mehr.

Was die Datenübermittlung angeht, sicher nicht. Was die Datenspeicherung auf dem Server angeht, selbstverständlich.

Nein, weil man, wenn man die md5 Summe auf dem Server hinterlegt hat, auch nur die md5 Summe zum einloggen braucht - denn auch der Server kann nicht raten, und da das Passwort ja nicht mehr im Klartext übertragen wird, sondern nur noch sha1(user+pass+challenge) kann man auch serverseitig das Passwort nicht mehr hashen. Ist auf dem Server also nur md5(pass) bekannt, muß CHAP auch mit sha1(user+md5(pass)+challenge) arbeiten.

Und zu irgendeinem Zeitpunkt muß zwangsläufig auch einmal ein unverschlüsseltes Passwort übermittelt werden: Wenn es geändert werden soll!

Nein, da muß nur der Unterschied zum alten Passwort übertragen werden.

Ich bleibe dabei: Es ist unsinnig, sich komplizierte Session- oder Loginpasswortverschleierungsmechanismen auszudenken. Wenn man Sicherheit haben möchte, muß man auf Standards zurückgreifen,

CHAP ist ein Standard.

und die lauten: 1. SSL,

mit einer Priese Man in the middle

2. Sichere Benutzerpassworte. SSL schließt das Abhören von Passworten aus, und ordentliche Passworte verhindern den direkten Angriff durch Ausprobieren.

Wir sprechen immernoch von Man in the Middle Attacken, richtig? SSL ist da keinen Millimeter besser als CHAP.

Deinen unfreundlichen Angriff mit "Quatsch" schiebe ich mal auf die unchristliche Uhrzeit, zu der man eigentlich keine gesalzenen Postings mehr verfassen sollte.

Definitiv nicht, wenn ich sage Quatsch, dann meine ich das auch so. Deine Behauptung, SSL würde alle Probleme der Welt lösen ist schlicht falsch und gefährlich, weil es die Benutzer in falsche Sicherheit wiegt.

Gruß, Bodo