Neues Passwort-Verschlüsselungssystem im ingame-Netzwerk

[Orion]

Tja was bringts wenn die Sicherheit hier erhöht wurde wenn so volldeppen überall das gleiche PW verwenden

Leute die aufgrund dessen gehackt werden haben es leider nicht anders verdient

 

[Culexus]

Eben nicht! Lange Passwörter (14 Zeichen und mehr) mit Sonderzeichen, Zahlen, und Groß- und Kleinschreibung sind nach wie vor der beste Schutz. Auch mit einem vergleichsweise schwachen Hashing. Mit unserem alten Verfahren wären die guten Passwörter auch immer noch sicher.

wollt nur diesen trockenen thread mit einem schönen bild auflockern

 

[stetel]

Dass ich das noch erleben darf nach über 10 Jahren

 

[BlueWulv]

Allerdings bleibt es dabei, sind die Passwörter zu einfach, dann werden sie auch geknackt werden.

Aber das werden sie schon ohne Zugriff auf die Datenbank überhaupt gehabt haben zu müssen

@ingame:
Danke und Respekt dafür! Das ist leider ein sehr selten genutzer Standard.

 

[mfb]

"Passwort", "123456" etc. als Passwörter kann man mit keinem Verfahren absichern - sowas ist sogar mit Ausprobieren über die reguläre Loginmöglichkeit knackbar.
Gleichzeitig sind sehr lange Passwörter ohne Wörterbucheinträge gegen Brute Force sicher, egal wie aufwändig das Verfahren ist. In beiden Fällen bringt das neue Verfahren also nicht allzu viel.
Aber die ganzen Passwörter dazwischen, die mit Brute Force zwar knackbar sein können, aber nicht im Wörterbuch stehen - bei denen bringt es etwas.


Das Problem bei 4 gewöhnlichen Wörtern hintereinander ist die Passwortlänge. Wenn man das Passwort häufiger braucht, kann das sehr nervig sein.

 

[UnleashTheBeast]

Mehrfaches Hashen ist doch eher sinnlos, gibt doch auch für hashes fertige Rainbowtables?

 

[acetous]

Die Nutzung von Rainbow Tables unterbindet man ja schon durch die Einführung eines Salts.

Edit: Zudem hat mehrfaches Hashen nix mit Rainbow Tables zu tun. Das macht man nur, um den Aufwand für Brutforce-Angriffe zu erhöhen. Dabei hat der Angreifer ja für jede Kombination den Mehraufwand.

 

[UnleashTheBeast]

Das ist (besonders bei unique salts für jedes pw) sehr richtig, aber wozu wird dann mehrfach gehasht?

 

[mfb]

Damit auch ein Angriff per Brute Force länger rechnen darf.

 

[UnleashTheBeast]

Wenn unique salts verwendet werden und ein ordentliches Hashing (und damit meine ich kein md5 oder sha1), rechnet Bruteforce auch so schon _SEHR_SEHR_ lange. Will jetzt hier niemanden kritisieren oÄ, aber finde mehrfaches hashing einfach sinnlos...

 

[DameVenusia]

Sinnlos ist es nicht. Davon abgesehen, wer hier ein Passwort falsch eingibt bekommt die Meldung:

"blabla, noch zehn Versuche frei, dann 60 Minuten Sperre".

da ist selbst mit ungesalzenen PWs oder gar Klartext Pws ziemlich schnell Schluss mit der Probiererei oder der Umgehungsaufwand wäre beträchtlich (wenn es eine Umgehung gäbe)

So oder so, das alte Verfahren war recht sicher, das neue ist nach heutigen Maßstäben überaus sicher. Wundert mich eh, dass kaum jemand eine Zeitsperre nach n-Versuchen einbaut.
Einfacher geht es wirklich nimmer gegen Rainbow-Tables oder Bruteforce-Attacken. (In der Kombi mit sicherer Verschlüsselung)

Edit: Gemeint sind natürlich die Zugriffe übers Web, wer die Datenbank hat, hat die Beschränkung natürlich nicht.

 

[Odysseus]

Nein. Ein MD5-Hash ist einfach zu schnell zu berechnen, selbst in zwei Runden mit Salt. Damit kann man schwache Passwörter sehr einfach brutforcen.

Man muss immer den Aufwand bedenken. Wenn du MD5 benutzt, beide Hash-Vorgänge (unterschiedlich) salzt und ein 8-stelliges Salz aus Zufallszeichen (oder besser) verwendest, ist das grundsätzlich noch sicher genug.
Ein reines Mehrfach-Hashing (v.a. ohne Salz, und mit MD5 oder quasi jedem anderen Algorithmus) hingegen ist absolut nicht zu empfehlen, weil man dadurch die Entropie sogar noch senkt. (Im Fall von MD5 werden dann ja ab dem 2. Schritt immer nur noch 32 bit lange Zeichen aus Hex-Zahlen weiter gehasht, und dabei kommen wieder immer nur 32 bit lange Zeichen aus Hex-Zahlen heraus usw.)
Als Bestandteil einer Hash-Strategie ist gegen MD5 eigentlich nichts einzuwenden. Im Idealfall benutzt man aber zusätzlich auch noch andere Algorithmen - richtig.

Nicht wirklich, MD5 ist quasi geknackt und gegen einfache salts gibt es auch schon rainbowtables.

Naja, "geknackt" ist etwas unzutreffend: Es ist gelungen, die Komplexität um einige Bits zu reduzieren. Aber bei der Verwendung ordentlicher Salts ist das wenig tragisch.
Da aber auch noch andere Hash-Algorithmen zur Verfügung stehen, spricht natürlich in der Tat nicht mehr so viel für MD5. Eigentlich gar nichts...


Wie auch immer: Eine Verbesserung der Account-Sicherheit ist zu begrüßen, wenngleich natürlich jedem Benutzer klar sein sollte, dass "123456" trotzdem kein klug gewähltes Passwort ist.

 

[acetous]

Die Entropie ist ja nur beim Eingabewert, d.h. Passwort mit Salt wichtig. Danach nutzt man mehrere Runden, weil man deren zusätzliche Berechnungszeit ausnutzen will, um den Angreifer auszubremsen. MD5 sollte man aber nicht mehr nutzen, da der Hash zu schnell berechnet wird. Bei Blowfish z.B. ist der Aufwand für die Berechnung eines Hashes viel höher, daher ist das heutzutage der Stand der Technik.

Falls ich da falsch liege, würde ich mich aber über weitere Quellen freuen, um zu sehen, was die Forschung dazu zu sagen hat.

 

[mfb]

Die Entropie ist ja nur beim Eingabewert, d.h. Passwort mit Salt wichtig.

Ich weiß nicht, ob MD5 128-Bit-Ketten (+Salt ggf.) bijektiv auf 128-Bit-Ketten abbildet, jedes Hashergebnis also nur von genau einem vorherigen Hashergebnis erzeugt werden kann (und damit gleichzeitig auch jedes Hashergebnis möglich ist). Falls nicht, geht ab der zweiten Iteration die Zahl der möglichen Passworthashes zurück.
Allerdings dürfte jeder sinnvolle Hashalgorithmus da wesentlich mehr Möglichkeit für Entropie haben als die Passwörter selbst.

 

[Dekker]

Ich weiß nicht, ob MD5 128-Bit-Ketten (+Salt ggf.) bijektiv auf 128-Bit-Ketten abbildet, jedes Hashergebnis also nur von genau einem vorherigen Hashergebnis erzeugt werden kann (und damit gleichzeitig auch jedes Hashergebnis möglich ist). Falls nicht, geht ab der zweiten Iteration die Zahl der möglichen Passworthashes zurück.

Eine kryptographische Hashfunktion darf unter keinen Umständen bijektiv sein! Sonst könnte man sie umkehren und damit wäre das Hashen völlig sinnbefreit.

Es ist schon traurig wie die ganzen Sicherheitsexperten hier Fachsimpeln und Begriffe durch de Gegend werfen die sie selbst nicht verstehen und dann oft auchnoch falsch verwenden.

 

[mfb]

Bijektiv heißt, dass sie mathematisch umkehrbar ist. Der reale Aufwand muss eben so hoch sein, dass das mit heutiger Computerleistung nicht möglich ist.

Wenn 128bit->128bit nicht bijektiv (und damit nicht injektiv) ist, würde das übrigens direkt Hash-Collisions bedeuten.

Anderes Beispiel: Jede Verschlüsselung muss injektiv und damit (für gültige verschlüsselte Texte) umkehrbar sein, schließlich soll der Empfänger sie entschlüsseln können. Bei asymmetrischen Verschlüsselungen ist die eine Richtung auch öffentlich bekannt. Das heißt nicht, dass jede Verschlüsselung völlig sinnbefreit wäre.

Es ist schon traurig, ... nein ich lasse den Kommentar sein.

 

[zerg123]

Hä, Laie und so, aber warum soll bitte jede Verschlüsselung injektiv sein? Ergibt doch keinen Sinn oder?
Man nehme Text 1, verschlüssele mit Schlüssel 1 und erhalte X.
Nur kann man dieses selbe X doch genauso mit Text 2 und Schlüssel 2 erhalten.

Oder ein anderes Beispiel
Man nehme Text 1 , 3 schlüssel und erhalte X. Jetzt kann man mit hilfe jeder dieser 3 Schlüssel aus X wieder Text 1 entschlüsseln.

 

[Odysseus]

Ich weiß nicht, ob MD5 128-Bit-Ketten (+Salt ggf.) bijektiv auf 128-Bit-Ketten abbildet, jedes Hashergebnis also nur von genau einem vorherigen Hashergebnis erzeugt werden kann (und damit gleichzeitig auch jedes Hashergebnis möglich ist).

Nein, ist nicht umkehrbar. Es ist ja gerade der Sinn beim Hashing, dass man vom Hash nicht auf den Ausgangswert schließen kann. Es ist dementsprechend auch möglich, dass man zwei Zeichenketten findet, die den selben MD5-Hash ergeben. Das trifft bei anderen Hash-Algorithmen auch zu. Es ist aber nicht weiter tragisch, denn der Hash-Algorithmus ist ja gerade drauf ausgelegt, dass die Wahrscheinlichkeit für solche Doppel-Vorkommnisse (Kollisionen) extrem gering ist. Und genau DAS ist da Problem bei MD5: Mittels entsprechender MEthodik kann der Angreifer "relativ" leicht solche Kollisionen provozieren und somit ein "Ersatz"-Passwort erzeugen. ("Relativ" mein, dass die Komplexität um einige Zehnerpotenzen geringer ist, als das bruteforcen des originalen Passworts.)

Mathematisch umkehrbar muss es nur sein, wenn man etwas verschlüsseln will. Und dabei soll es natürlich im Idealfall (^^) so sein, dass man es mit Kenntniss des Passwortes (bzw. des geheimen Schlüssels) extrem schnell & leicht wieder umwandeln (=entschlüsseln) kann, aber ohne diese Kenntnis nur extrem langsam & schwer.

Wie du aber richtig sagst, geht beim Hashing - und insbesonders bei MD5 - ab der 2. Iteration die Mögliche Anzahl an Ergebnis-Hashes zurück, weil man dann immer nur wieder und wieder Hashes, die einem bestimmten Muster folgen, hasht: Bei MD5 würde man ab der 2. Itertion immer nur 32 bit lange Strings die nur auf 0-9 und A-F bestehen weiter verarbeiten und so die Komplexität reduzieren. Daher ist es ja so wichtig, bei iterativem Hashing auch sinnvolle (!) Salts zu verwenden. Sonst wird aus dem vermeintlichen Mehr an Sicherheit schnell ein Weniger.

Die Idee, das Hashen durch zahlreiche Iterationen zu einem zeitlich aufwändigen Vorgang zu machen, ist durchaus üblich und bei der Abwehr von Bruteforce-Angriffen schon ganz sinnvoll. Insbesonders ist das dann nützlich, wenn man sich vor "Datenbank-Dumps" und daraus geklauten Passwort-Hashes schützen will: Denn während man in z.B. einem Forum eine Funktion einbauen kann, dass man nach 5x falscher Eingabe erst mal 15 Minuten warten muss, kann man das einem Cracker, der den Datenbank-Inhalt ergaunert hat, eher nicht so einfach verbieten. ^^

Eigentlich ein schönes Thema, das aber im Grunde nix mit diesem Thread zu tun hat... ^^

 

[Dekker]

Bijektiv heißt, dass sie mathematisch umkehrbar ist. Der reale Aufwand muss eben so hoch sein, dass das mit heutiger Computerleistung nicht möglich ist.

Nenne mir eine Bijektive Funktion, die mit realem Aufwand kaum umkehrbar ist.
Edit: Keyed Funktions, ups :E

Wenn 128bit->128bit nicht bijektiv (und damit nicht injektiv) ist, würde das übrigens direkt Hash-Collisions bedeuten.

Aber genau das ist das wichtigste Kriterium einer kryptographischen Hashfunktion. Diese müssen eine Einwegfunktion darstellen. Es gibt natürlich Hashfunktionen die bijektiv sind, diese kommen aber bei Datenstrukturen zum Einsatz, sicherlich aber nicht um Passworte zu schützen. Schau dir am besten mal die Typischen kryptographischen Hashfunktionen an und kuck dir Verhältnis von Eingabelänge und Ausgabelänge an. Solltest du eine kryptographische Hashfunktion finden, bei der Eingabelänge = Ausgabelänge gilt, kannst du sie mir gerne nennen.

Anderes Beispiel: Jede Verschlüsselung muss injektiv und damit (für gültige verschlüsselte Texte) umkehrbar sein, schließlich soll der Empfänger sie entschlüsseln können. Bei asymmetrischen Verschlüsselungen ist die eine Richtung auch öffentlich bekannt. Das heißt nicht, dass jede Verschlüsselung völlig sinnbefreit wäre.

Ja stimmt, aber was hat asymmetrische Verschlüsselung jetzt mit einer Hashfunktion zu tun? Verschlüsselungen und Hashen haben erstmal wenig miteinander zu tun.

Es ist schon traurig, ... nein ich lasse den Kommentar sein.

Es ist in der Tat besser das du den Kommentar weg hast fallen lassen. Wär ziemlich in die Hosegegangen.

Edit:
Übrigens warst du nicht gemeint mit meinem Kommentar vorher, sondern vielmehr einige andere. Das hätte ich deutlicher machen sollen. Auf dich bezog sich nur das mit der bijektivität. Der Zweite absatz war nicht auf dich gemünzt

 

[mfb]

Hä, Laie und so, aber warum soll bitte jede Verschlüsselung injektiv sein? Ergibt doch keinen Sinn oder?
Man nehme Text 1, verschlüssele mit Schlüssel 1 und erhalte X.
Nur kann man dieses selbe X doch genauso mit Text 2 und Schlüssel 2 erhalten.

Oder ein anderes Beispiel
Man nehme Text 1 , 3 schlüssel und erhalte X. Jetzt kann man mit hilfe jeder dieser 3 Schlüssel aus X wieder Text 1 entschlüsseln.

Der Schlüssel gehört zur Funktion. Injektiv bedeutet also "bei gleichem Eingabetext und gleichem Schlüssel kommt der gleiche verschlüsselte Text heraus". Oder, konkreter: Lasse das Verschlüsselungsprogramm zweimal laufen, und du erhälst zweimal das gleiche Ergebnis.


@Odysseus: Ich bezog mich lediglich auf das erneute Hashen, also das Anwenden der Hash-Funktion auf einen 128bit-String (oder was auch immer die Länge des jeweiligen Hashs ist).

Wie du aber richtig sagst, geht beim Hashing - und insbesonders bei MD5 - ab der 2. Iteration die Mögliche Anzahl an Ergebnis-Hashes zurück, weil man dann immer nur wieder und wieder Hashes, die einem bestimmten Muster folgen, hasht: Bei MD5 würde man ab der 2. Itertion immer nur 32 bit lange Strings die nur auf 0-9 und A-F bestehen weiter verarbeiten und so die Komplexität reduzieren.

Ich würde erwarten, dass der Output der einen Iteration dann in seiner Binärform einfach als Input der nächsten verwendet wird, ohne das in (Ascii?) [0-9A-F] zu verwandeln. Man hat also immer 128bit-Ketten und die Darstellung über Hexadezimalzahlen ist keine Einschränkung. Und da ist eben die Frage, ob man die Zahl der Möglichkeiten weiter reduziert.


@Dekker:

Nenne mir eine Bijektive Funktion, die mit realem Aufwand kaum umkehrbar ist.

Jede asymmetrische Verschlüsselung nutzt solche Funktionen. Sie ist injektiv (muss sein, siehe oben), also kann man den Wertebereich einfach so weit einschränken bis sie auch surjektiv ist. Da der public key bekannt ist, ist die eine Richtung öffentlich nachvollziehbar. Mathematisch gesehen ist die Verschlüsselung also leicht zu knacken. Aber real eben nicht, außer das Verschlüsselungsverfahren ist schlecht.

>> Solltest du eine kryptographische Hashfunktion finden, bei der Eingabelänge = Ausgabelänge gilt, kannst du sie mir gerne nennen.
Wie bereits erwähnt bezog ich mich auf den Fall, dass ein Hash erneut durch die Hashfunktion geschickt wird, und dort ist Eingabelänge=Ausgabelänge.

Ja stimmt, aber was hat asymmetrische Verschlüsselung jetzt mit einer Hashfunktion zu tun? Verschlüsselungen und Hashen haben erstmal wenig miteinander zu tun.

Von dir stammte die Aussage, dass "bijektiv => leicht umkehrbar". Ich habe ein Gegenbeispiel geliefert.

Übrigens warst du nicht gemeint mit meinem Kommentar vorher, sondern vielmehr einige andere. Das hätte ich deutlicher machen sollen. Auf dich bezog sich nur das mit der bijektivität. Der Zweite absatz war nicht auf dich gemünzt

Ah ok, danke.