Benutzerauthentifikation in Windows

Dieses Thema im Forum "Sicherheit & Datenschutz" wurde erstellt von Soulrunner, 12. Februar 2011 .

Schlagworte:
  1. 12. Februar 2011
    Hallo,

    gezwungenermaßen beschäftige ich mich mit o. g. Thema.

    Verstanden habe ich Folgendes:

    Nutzer gibt Kennung und Kennwort ein, letzteres durchläuft eine Hashfunktion. Das Ergebnis wird mit den Datensätzen in SAM abgeglichen.
    Es ist nahezu unmöglich, das exakte Kennwort über den Hashwert herauszubekommen.

    ABER: Wozu benötige ich das exakte Kennwort überhaupt? Windows gleicht doch lediglich den Hashwert ab; d. h. es gibt viele "Nebenkennwörter", die den gleichen Hashwert ergeben. Wo ist denn da dann die Sicherheit? Oder ist es i. d. R. einfach zu aufwendig, solche "Nebenkennwörter" zu ermitteln?

    Für Eure Hilfe wäre ich sehr dankbar :]
     
    + Multi-Zitat Zitieren
  3. 12. Februar 2011
    AW: Benutzerauthentifikation in Windows

    Die Sache mit den Nebenkennwörtern stimmt so nicht. Wie kommst du darauf, dass es mehrere Passwörter mit einem Hash gibt?

    Kryptologische Hashfunktion – Wikipedia

    Es ist auch nicht weiter schwer das echte Passwort über den Hash zu bekommen (so lange der Hash nicht salted ist) Stichwort: Rainbowtables. (Rainbow Table – Wikipedia)

    Du brauchst also zwingend das Passwort im Klartext damit du dich anmelden kannst (sofern alles korrekt implementiert wurde.)
     
    + Multi-Zitat Zitieren
  4. 12. Februar 2011
    AW: Benutzerauthentifikation in Windows

    Erstmal danke für die schnelle Antwort!

    Bisher habe ich gelesen, dass der "Vorteil" einer Hashfunktion der ist, dass man anhand eines Hashwertes nicht eindeutig auf ein Kennwort schließen kann.

    Ein einfaches Beispiel:

    Ein Kennwort wird mit "9" codiert und in die Hashfunktion H(m) = m mod 7 gegeben.
    also H(9)= 2. Aber es gilt doch auch z. B. H(16) = 2.

    Es gibt also mehrere Kennwörter, die einen Hash ergeben oder nicht?

    Ein zugegeben einfacher Algorithmus; mir ist auch bekannt, dass ein Kennwort hexadezimal in die Hashfunktion eingelesen wird.

    EDIT: Aha, okay, aber grundsätzlich ist es möglich, zu x ein x' mit gleichem Wert zu finden? Ich muss mich erstmal einlesen..sry aber hab mich noch nie bisher mit Kryptografie in der IT (bewusst) beschäftigt.
     
    + Multi-Zitat Zitieren
  5. 12. Februar 2011
    AW: Benutzerauthentifikation in Windows

    Habe meinen letzten Post noch nach editiert. Er sollte nun deine Fragen beantworten.

    //Edit:

    Message-Digest Algorithm 5 – Wikipedia

    Kannst du dir ja mal anschauen.
     
    + Multi-Zitat Zitieren
  6. 13. Februar 2011
    AW: Benutzerauthentifikation in Windows

    Natürlich gibt es bei einer Hashfunktion immer mehrere Eingaben, die zum selben Hash-Wert führen. Das muss ja schon so sein, wenn die Eingabe belieb lang sein darf, der Hash aber etwa nur 128-Bit lang ist: Dadurch gibt es ja nur 2^128 Möglichkeiten. Probiert man jetzt 2^129 verschiedene Eingaben, ist zu erwarten, das im Schnitt jeder Hash zwei mal angenommen wird.

    Nun ist es aber so, dass eine Hashfunktion genau dann gut und sicher ist, wenn es sehr schwierig (bzw. praktisch unmöglich) ist, für einen Hash irgendeine passende Eingabe zu finden.
    Insbesondere soll es sogar schwierig sein, zwei vollkommen beliebige Eingaben zu finden, welche zum selben Hash führen (was bei MD5 etwa inzwischen nicht mehr gegeben ist!).

    Auf Grund dieser geforderten Eigenschaften ist es eben nicht ganz einfach, eine gute Hashfunktion zu gestalten. MD5 sollte ja auch kollisions-resistent sein, was sich jetzt nach einigen Jahren aber als unzulänglich erwiesen hat.

    Zu Deiner zweiten Frage, warum das Klartext-passwort überhaupt gebraucht wird:
    Das System hat ohnehin die absolute "Hoheit" und kann machen, was es will. Es wird ja mit dem Passwort nichts verschlüsselt, das System muss nur irgendwie prüfen können, ob das Passwort korrekt ist. Dazu könnte man das Klartext-Passwort auch in irgend ein geschützten Bereich speichern, damit da niemand rankommt - aber das ist eben nicht so sicher, wie einfach eine Hashfunktion darauf anzuwenden. Weil das System selbst immer diese Hashfunktion auf das Passwort anwendet, hilft dir der Hash alleine aber auch nichts - Du müsstest schon im System irgendwie die Prüfung umschreiben. Aber wenn Du in der Lage bist, die Prüfung umzuschreiben, kannst Du sie auch gleich ganz entfernen - darum ist der Hash alleine für Dich (zumindest theoretisch) wertlos.
     
    + Multi-Zitat Zitieren
  7. 13. Februar 2011
    AW: Benutzerauthentifikation in Windows

    Diese 2 Eingaben unterscheiden sich dann aber erst ab dem 128sten Bit. In der Praxis zieht man also keinen großen Vorteil daraus.

    Ich meine, was habe ich davon wenn:

    12345678910

    den gleichen Hashwert gibt wie

    12345678910abcd

    Ich werde doch sowieso erst auf 12345678910 treffen.
     
    + Multi-Zitat Zitieren
  8. 13. Februar 2011
    AW: Benutzerauthentifikation in Windows

    Hallo zusammen

    Eventuell jetzt einwenig Offtopic.
    Aber bei einer Verschlüsselung ist es ja immer so, das man das ganze eigentlich in umgekehrter Reihenfolge (reverse) ablaufen lassen könnte und man dan auf das Passwort kommt.
    Also crypten und decrypten.
    Warum muss man jetzt z.B den Hash brute-forcen um an das eig. passwort zu kommen und kann ihn nicht berechnen?

    Als kleines Beispiel
    Wenn ich weiss
    A wird ersetzt durch 1 (nur ein beispiel
    B durch 2
    C durch 3
    etc.

    Dann kann ich wenn ich ja die Anzahl versetzter buchstaben habe das ganze "einfach" entschlüsseln.

    Hoffe jemand kapiert was ich da meinte.
     
    + Multi-Zitat Zitieren
  9. 13. Februar 2011
    AW: Benutzerauthentifikation in Windows

    Weil Hashen != Verschlüsseln ist. Das ist ja das besondere an einem Hash. Man kann nicht auf den Klartext schließen.
     
    + Multi-Zitat Zitieren
  10. 13. Februar 2011
    AW: Benutzerauthentifikation in Windows

    Nö. Stichwort asymmetrische Verschlüsselung (welche heutzutage Standard ist), siehe zB hier.

    Und bei Passwörter is das eh nochmal was anderes, weil wie Alex schon sagte, ein Hash keine Verschlüsselung ist, sondern eine Abbildung des Passworts.

    Das ist wie wenn du nur den Schatten eines Menschen siehst. Wenn du Mensch und Schatten vergleichst, kannst du die beiden eindeutig zueinander zuordnen. Aber anhand des Schattens zu rekonstruieren wie der Mensch aussieht ist unmöglich.

    Gruß,
    Figger
     
    + Multi-Zitat Zitieren
  11. 13. Februar 2011
    AW: Benutzerauthentifikation in Windows

    Ich glaube ihr braucht das hier:
    CRYPTOOL PORTAL - CRYPTOGRAPHY AND CRYPTANALYSIS

    Am besten mit CrypTool v1 rumspielen und danach zu CrypTool v2 übergehen... CrypTool v2 ist schon mega geil um das Zeug zu verstehen, aber leider noch Beta.
     
    + Multi-Zitat Zitieren
  12. 13. Februar 2011
    AW: Benutzerauthentifikation in Windows

    Hallo,
    hashes sind "Einweg-Verschlüsselungen". "Einweg-Verschlüsselungen" kann man nicht mehr zurück berechnen.

    Am besten zeige ich es euch Anhand eines Beispiels (sehr abstrakt):

    Mein Passwort lautet: 68967

    Nun setze ich den Kirill Hash-Algorithmus ein.

    Kirill Hash-Algorithmus ergibt die Prüfsumme: 36


    Wie funktioniert nun der Kirill Hash-Algorithmus?
    Er bildet einfach nur die Quersumme aus dem Passwort.

    --

    Anhand der Prüfsumme kann man nicht mehr eindeutig mein Passwort zurückrechnen, da auch das Passwort: 9999 etc. die Prüfsumme: 36 ergeben würde.

    Die echten Hash-Algorithmen sind da halt viel komplexer, die bei jeder Prüfsumme eine bestimmte "Verschlüsselungsstärke" ergeben (128 Bit etc.) und sind so ausgelegt, dass es theoretisch nur eine eindeutige Prüfsumme ergeben sollte. Ergeben zwei Passwörter oder Daten die selbe Prüfsumme, dann spricht man von einer Kollision.

    Wie in meinem Beispiel ergäbe der Kirill Algorithmus viele Kollisionen. Ich gebe zu, mein Algorithmus ist nicht sehr durchdacht.



    Ich hoffe, dass ich nun manchen ungefähr die Funktionsweise eines Hashes bzw. den Begriff "Einweg-Verschlüsselung" erklären/verdeutlichen konnte.


    Grüße
    Kirill
     
    + Multi-Zitat Zitieren
  13. 13. Februar 2011
    AW: Benutzerauthentifikation in Windows

    geniales programm! das hätte ich vor 2 jahren im informatik LK gebraucht hätte mir viel zeit erspart^^
     
    + Multi-Zitat Zitieren
  14. 13. Februar 2011
    AW: Benutzerauthentifikation in Windows

    Habe es gerade auch ausprobiert, ist total cool. Danke noch mal @ N0S!!
     
    + Multi-Zitat Zitieren
  15. 14. Februar 2011
    AW: Benutzerauthentifikation in Windows

    Es ging mir nur darum, zu erläutern, dass es Kollisionen geben muss. Wie man die bekommt und was man damit anstellt ist dann wieder eine andere Geschichte.

    Nicht ganz. Einige Hashfunktionen basieren tatsächlich auf symmetrischen Block-Chiffren.
    Jedoch ist es eben so, dass wenn man den Schlüssel nicht kennt, moderne Kryptoalgorithmen so konstruiert sind, dass es extrem aufwändig ist (bzw. praktisch unmöglich), etwas zu entschlüsseln. Hashfunktionen kann man sich dann so vorstellen, dass man einfach den Schlüssel wegwirft. Damit kommt man vom Hash auch nicht mehr zur Eingabe.
     
    + Multi-Zitat Zitieren
  16. 21. Februar 2011
    AW: Benutzerauthentifikation in Windows

    Beim Hashen verliert man doch aktiv Daten, die nicht mehr vorhanden sind. Das ist für mich schon ein entscheidener Unterschied. Da machst du mit einem Schlüssel auch nichts mehr, da die Daten ja einfach nicht vorhanden sind.

    Ein Hash-Algorythmus verfolgt im Endeffekt ein anderes Ziel als eine Verschlüsselung.
    (Wenn auch sehr Allgemein der Schutz von irgendetwas immer das Ziel ist.)

    Das war keine Kritik an deinem Beitrag, sondern eine Erweiterung im Bezug zur Praxis.
     
    + Multi-Zitat Zitieren
  17. 21. Februar 2011
    AW: Benutzerauthentifikation in Windows

    Stichwort: Collision attack
    Collision attack - Wikipedia, the free encyclopedia

    Auch wenn das bei Passwörtern natürlich keine Rolle spielt. In anderen Szenarios hat man was davon.
     
    + Multi-Zitat Zitieren
  18. 21. Februar 2011
    AW: Benutzerauthentifikation in Windows

    In welchen? Und ich beziehe mich auf genau diese Art von Kollision, wie ich sie beschrieben habe. Das Kollisionen an sich keine tolle Sache sind, was die Sicherheit angeht ist mir klar.
     
    + Multi-Zitat Zitieren
  19. 22. Februar 2011
    AW: Benutzerauthentifikation in Windows

    Wenn man Dokumente digital signiert, wird üblicherweise nur der Hash des Dokumentes signiert.
    Habe ich jetzt eine beliebige(!) Kollision, kann ich zwei Dokumente erstellen: Etwa einen mir ungünstigen und einen mir vorteilhaften Vertrag. Dann fange ich an, beide Dokumente solange zu verändern, in dem ich etwa Leerzeichen hinzufüge etc. bis beide Dokumente in den gleichen Hash resultieren. Das mir unvorteilhafte Dokument gebe ich dann zum Unterschreiben meinem Gegenüber - der macht das ja gerne, weil es für mich scheinbar nachteilig ist. Damit unterschreibt er aber (unwissentlich) auch den mir vorteilhaften Vertrag, den ich dann meinetwegen einklagen kann.
    Rein praktisch hat sich das ganze schon so geäussert, dass jemand sich ein SSL Zertifikat für http://www.fdjslk.de hat signieren lassen (dadurch ist es gültig und wird von jedem Browser akzeptiert). Durch eine Hash-Kollision wurde dadurch aber auch Microsoft Corporation (oder so, weiss nicht mehr genau, was) signiert und der Angreifer hat ein korrektes Zertifikat für microsoft.com
    Darum auch Vorsicht mit SSL Zertifikaten, die nur MD5 gehashed wurden
     
    + Multi-Zitat Zitieren
  20. Video Script

    Videos zum Themenbereich

    * gefundene Videos auf YouTube, anhand der Überschrift.

Auf dieses Thema antworten