1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Datenleck: Warum Knuddels seine…
  6. T…

Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: Auspuffanlage 10.09.18 - 18:36

    TrollNo1 schrieb:
    --------------------------------------------------------------------------------
    > Das schöne an Rainbow Tables und Hashes ist ja, dass das originale Passwort
    > völlig egal ist. Es genügt ein Input, der denselben Hash erzeugt. Man
    > benötigt also nur eine Table, die alle möglichen Hashes enthält und man hat
    > auch ein zwei Millionen stelliges Passwort "geknackt", da es ein viel
    > kürzeres Wort gibt, das denselben Hash ergibt.

    Das müsste dann aber voraussetzen das kein hash benutzt wird, weil wenn die Passwörter gehasht werden, dann benötigst du ja auch den hash (der wird ja nur in der dB sein und zum überprüfen benutzt).
    Heißt du benötigst bei entsprechendem input zusätzlich den salt und musst dann einen Output haben der mit dem alten identisch ist.
    Oder habe ich da jetzt was falsch verstanden?

  2. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: 24g0L 10.09.18 - 19:00

    Quantium40 schrieb:
    --------------------------------------------------------------------------------
    > PhilippK schrieb:
    > > Das stimmt so auch nicht. Dank des Salts lässt sich die geleakte
    > Datenbank
    > > wenigstens nicht mit einer anderen, die denselben Hashalgorithmus nutzt,
    > > abgleichen.
    >
    > Wenn alle gehasten Einträge den selben Salt benutzen, dann muss ein
    > Angreifer genau ein Rainbowtable errechnen lassen oder aber einmal seine
    > Wortlisten mit diesem Salt durch den Algorithmus durchlaufen lassen.
    > Ist ein unterschiedlicher Salt bei jedem Eintrag, dann steigt der Aufwand
    > für den Angreifer enorm an, weil er dies für jeden unterschiedlichen Salt
    > erneut tun muss.

    Für die Dummen aber Interessierten unter uns: Wie weiss der Server, welcher User welches Salt verwendet? Gespeichert kann es ja nicht werden, sonst hätte das der Hacker ebenfalls. Ist es also eine Operation, die auf des Users Attributen basiert, zum (blöden) Beispiel sein Vorname konkateniert mit seinem Nachnamen? Oder müsste konsequenterweise das Salt vom User zusätzlich zum Passwort eingegeben werden (sowohl bei der Registrierung als auch bei jedem Anmelden), damit das Salt nie persistiert wird?
    Fragen über Fragen... :-)

  3. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: PhilippK 10.09.18 - 19:18

    24g0L schrieb:
    --------------------------------------------------------------------------------
    > Quantium40 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > Für die Dummen aber Interessierten unter uns: Wie weiss der Server, welcher
    > User welches Salt verwendet? Gespeichert kann es ja nicht werden, sonst
    > hätte das der Hacker ebenfalls. Ist es also eine Operation, die auf des
    > Users Attributen basiert, zum (blöden) Beispiel sein Vorname konkateniert
    > mit seinem Nachnamen? Oder müsste konsequenterweise das Salt vom User
    > zusätzlich zum Passwort eingegeben werden (sowohl bei der Registrierung als
    > auch bei jedem Anmelden), damit das Salt nie persistiert wird?
    > Fragen über Fragen... :-)

    Das Salt kann getrost mit dem Passworthash gespeichert werden. Es geht darum, solche Angriffe wie Rainbowtable-Attacken zu verhindern.

    Mal angenommen, du würdest dir die Duden-Datenbank ziehen und von jedem deutschen Wort den Hashwert errechnen und dann die (Wort, Hashwert)-Tupel in einer Datei abspeichern.

    Dann kommst du irgendwie an die Nutzerdatenbank von Golem.de und gleichst einfach mal alle dort enthaltenen Passworthashes mit deiner Datei ab. Angenommen mein Passwort wäre "Passwort", so müsstest du einen Treffer erzielen, da das Wort im Duden steht.

    Würdest du aber nicht, da der gespeicherte Hashwert nicht Hash("Passwort") sondern Hash("SaltVonPhilippK;Passwort") o.Ä. ist. Also musst du für jeden einzelnen Nutzer noch einmal den ganzen Duden neu hashen, wodurch sich der benötigte Aufwand für das Herausfinden der Passwörter vervielfacht.

  4. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: 24g0L 10.09.18 - 19:31

    PhilippK schrieb:
    --------------------------------------------------------------------------------
    > Also musst du für jeden
    > einzelnen Nutzer noch einmal den ganzen Duden neu hashen, wodurch sich der
    > benötigte Aufwand für das Herausfinden der Passwörter vervielfacht.

    Ok, verstanden. Danke. Deine Aussage bezieht sich aber auf das Ziel, die Passwörter sämtlicher User zu kriegen. Mein Gedanke war, dass man sich auf einen gezielten Account beschränkt (z.B. Admin-Account oder identifiziertes Opfer). Dann würde ich mit dem bekannten Salt sämtliche Duden-Einträge durchrechnen und mit dem Eintrag in der Golem-DB vergleichen. In diesem Falle wäre das Salt keine echte Hürde, oder?

  5. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: dura 10.09.18 - 19:38

    Das kommt immer darauf an, wo man den Salt speichert, dadurch kann man schon weitere Hürden einrichten. Man kann z.B. einen Userbezogenen-Teil in der DB speichern und einen generischen Teil im Code. So käme (wenn die Teile stark genug sind) mit einem DB-Dump selbst nicht so weit.
    Aber auch da kann man sich natürlich immer weiter hangeln.

  6. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: BLi8819 10.09.18 - 20:29

    > Es genügt ein Input, der denselben Hash erzeugt.

    Sofern man aktuelle sichere Hash-Verfahren nutzt, kommt dies aber nicht vor. Solltest es dir bei einem aktuellen Verfahren gelingen so eine Kollision zu finden, solltest du diese publik machen.

  7. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: Quantium40 10.09.18 - 20:30

    24g0L schrieb:
    > Ok, verstanden. Danke. Deine Aussage bezieht sich aber auf das Ziel, die
    > Passwörter sämtlicher User zu kriegen. Mein Gedanke war, dass man sich auf
    > einen gezielten Account beschränkt (z.B. Admin-Account oder identifiziertes
    > Opfer). Dann würde ich mit dem bekannten Salt sämtliche Duden-Einträge
    > durchrechnen und mit dem Eintrag in der Golem-DB vergleichen. In diesem
    > Falle wäre das Salt keine echte Hürde, oder?

    Selbst dann hilft ein Salt, wenn auch in weitaus geringerem Maße, da mit Salt auch für diesen einen speziellen User dann ein vollständiger Angriff nötig wird, ohne dass die Möglichkeit besteht, vorausberechnete Hashes als Grundlage zum Knacken zu nutzen.

  8. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: Quantium40 10.09.18 - 21:06

    BLi8819 schrieb:
    > Sofern man aktuelle sichere Hash-Verfahren nutzt, kommt dies aber nicht
    > vor. Solltest es dir bei einem aktuellen Verfahren gelingen so eine
    > Kollision zu finden, solltest du diese publik machen.

    Kollisionen kommen bei allen Hashfunktionen zwangsläufig vor.
    Schlimm wird es nur, wenn man für beliebige Hashes mit geringem Aufwand Kollisionen errechnen kann.

  9. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: Kuma 10.09.18 - 21:08

    Mal eine Frage, würde es die Sicherheit erhöhen, wenn nach jedem login, die salt und demzufolge auch die hash neu generiert würden?

  10. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: Quantium40 10.09.18 - 21:15

    Kuma schrieb:
    > Mal eine Frage, würde es die Sicherheit erhöhen, wenn nach jedem login, die
    > salt und demzufolge auch die hash neu generiert würden?

    Nein. Für einen Angreifer ändert das nichts, da er ja Hash und Salt in der zueinander passenden Variante hat. Das Passwort selbst hingegen bleibt ja an der Stelle eine Konstante.

  11. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: redmord 10.09.18 - 21:22

    Eigentlich überhaupt nicht. Zu dem Zeitpunkt des Verlusts, verliert man einen funktionierenden Datensatz.
    Ob du neu den Salt erneuerst ändert nichts daran, dass der Angreifer, das Passwort via Brute-Force erraten hat/kann.

    Einzig die Möglichkeit von Kollisionen würde dies vorbeugen können. Generell kann man den Salt auch aus dem Passwort selbst generieren. Würde aber auch nicht wirklich was ändern.

    Es ist völlig okay, wenn der Salt neben dem Hash liegt. Es geht hier nur um die Vermeidung von Raindbow-Tables.

    Das wichtigste ist ein aufwendiger Hash-Algorithmus.

  12. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: Phantom 10.09.18 - 21:46

    Kennt ihr einen guten und vertrauenswürdigen Passwort Manager?

     Seid ihr oft im Wolkenbezirk?



    1 mal bearbeitet, zuletzt am 10.09.18 21:46 durch Phantom.

  13. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: eidolon 10.09.18 - 21:47

    PhilippK schrieb:
    --------------------------------------------------------------------------------
    > Hat man aber eine RT mit Kombinationen englischer
    > Wörter bis zu einer bestimmten länge, ist es trivial zu knacken.

    Sicher? Selbst wenn es nur 1 Mio Wörter sind, hat man bei 4 zufälligen Wörtern 1000000000000000000000 Kombinationsmöglichkeiten. Und wenn dann noch Groß- und Kleinschreibung beachtet wird, ists noch komplexer.

    Und wer sagt denn, dass das englische Wörter sind? ;)

  14. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: redmord 10.09.18 - 22:21

    Zettel und Stift! :-)

    Keepass ist guter alter Standard. "Cloud"-Lösungen, die irgendwelche Unternehmen hosten, mag ich persönlich nicht so gerne. Da gab es auch schon Leaks.
    Keepass lässt sich leider nur umständlich auf mehreren Geräten nutzen... mal von Cloudstorage zum syncen abgesehen.

    https://lesspass.com/ ist tatsächlich noch eine interessante Idee. Passwörter werden nicht gespeichert sondern aus von dir bekannten Informationen jedes mal neu generiert.

    Möglichkeit: Masterpassword + Email-Adresse + URL = Passwort für URL

  15. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: KloinerBlaier 11.09.18 - 08:15

    Es macht meiner Meinung nach durchaus Sinn, in den Salt irgendwelche persönlichen Informationen des Nutzer einzustreuen und ihn nicht direkt abzuspeichern.
    Daraus ergibt sich natürlich für den Angreifer der Aufwand, erstmal herauszufinden, dass ein Salt verwendet wurde und dann natürlich den entsprechenden Salt zu bestimmen.

    Auf irgendeiner Konferenz habe ich mal von dem Ansatz gehört, eine persönliche Information A des Nutzers zu hashen und den Hash dann als Salt gemeinsam mit dem Passwort zu hashen. Klang soweit eigentlich ganz interessant. Darauf muss man als Angreifer dann natürlich erstmal kommen.

  16. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: SJ 11.09.18 - 10:32

    pass

    https://www.passwordstore.org/

    In Bash geschrieben, einfach zu benutzen. Verwendet einfache Baumstruktur zum sichern. Beim sichern wird das alles mit GPG verschlüsselt.

    Kann mit git getrackt werden (integrierte Funktionalität) und so auf mehreren Geräten verwendet und synchronisiert werden. Theoretisch speicherbar auf nem öffentlich git server wie github/gitlab aber allenfalls möchte man die Struktur nicht öffentlich haben e.g. pass insert -m MeinePRONSites/roteRöhre.com

    Unter Linux gibts auch Gui z.B. qtpass
    Auf Android kanns in Termux betrieben werden oder auch mit Gui
    Unter Windows 10 kann man es z.B. via WSL benutzen

    Gibt bestimmt noch andere Möglichkeiten.

    --
    Wer all meine Fehler findet und die richtig zusammensetzt, erhält die geheime Formel wie man Eisen in Gold umwandeln kann.



    1 mal bearbeitet, zuletzt am 11.09.18 10:34 durch SJ.

  17. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: BLi8819 11.09.18 - 20:04

    Ja, aber alles andere wäre ja auch Brute Force und ist immer möglich.

  18. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: BLi8819 11.09.18 - 20:13

    > Keepass lässt sich leider nur umständlich auf mehreren Geräten nutzen...

    Warum?
    Man kann die Passwort-Datei doch auf ein Stick speichern und auf den Endgeräten jeweils Keepass installieren bzw. die Portale Version nutzen oder nicht?
    Habe ich jetzt noch nie gemacht, aber was spricht dagegen?

    Außer du meinst ein Sync mit Android oder iOS.

  19. Re: Und Passwörter sollten nicht nur gehasht werden, sondern auch noch ein Salt enthalten

    Autor: andy01q 12.09.18 - 14:36

    PhilippK schrieb:
    --------------------------------------------------------------------------------
    > andy01q schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Aktuell sind die Rainbow-Tables noch nicht lang genug, dass Kollisionen
    > > wahrscheinlich sind, aber das kann noch kommen.
    >
    > Eher nicht. Nimmt man die 160 Bit-Hashes aus meiner Rechnung von oben her,
    > gibt es knapp 10^49 verschiedene solcher Hashes. Man geht davon aus, dass
    > es auf der Erde etwa 10^50 Atome gibt. Daher ist es höchst
    > unwahrscheinlich, dass jemand in diesem Jahrtausend eine RT mit allen
    > 160-Bit Hashes erstellt.

    Nur durch erhöhte Rechenleistung wird das nicht passieren.
    Aber evtl. findet man Abkürzungen. Bei MD5 ist das Erzeugen von Kollisionen derzeit einfach, bei Sha1 möglich, aber schwer. (Sha1 hat gerade 160 bit) Bevor ein Hash durch Kollisionserzeugung gänzlich unbrauchbar wird kann es eine Zwischenphase geben in der man mit viel Aufwand komplexe Metarainbowtables erstellen kann aus denen sich alle fehlenden Hashes mit vertretbarem Aufwand vor Ort errechnen ließen.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Cohline GmbH, Dillenburg
  2. Possehl Spezialbau GmbH, Sprendlingen
  3. Regierung von Oberbayern, München
  4. eQ-3 AG, deutschlandweit, idealerweise Mitteldeutschland

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. GeForce RTX 3070 TUF O8G 8192 MB GDDR6 für 677,30€)
  2. (u. a. Zotac Geforce RTX 3070 Twin Edge 8 GB (ZT-A30700E-10P) für 799€)
  3. ab 499€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Ausprobiert: Meine erste Strafgebühr bei Free Now
Ausprobiert
Meine erste Strafgebühr bei Free Now

Storniert habe ich bei Free Now noch nie. Doch diesmal wurde meine Geduld hart auf die Probe gestellt.
Ein Praxistest von Achim Sawall

  1. Gesetzentwurf Weitergabepflicht für Mobilitätsdaten geplant
  2. Personenbeförderung Taxibranche und Uber kritisieren Reformpläne

SSD vs. HDD: Die Zeit der Festplatte im Netzwerkspeicher läuft ab
SSD vs. HDD
Die Zeit der Festplatte im Netzwerkspeicher läuft ab

SSDs in NAS-Systemen sind lautlos, energieeffizient und schneller: Golem.de untersucht, ob es eine neue Referenz für Netzwerkspeicher gibt.
Ein Praxistest von Oliver Nickel

  1. Firecuda 120 Seagate bringt 4-TByte-SSD für Spieler

The Secret of Monkey Island: Ich bin ein übelriechender, groggurgelnder Pirat!
The Secret of Monkey Island
"Ich bin ein übelriechender, groggurgelnder Pirat!"

Das wunderbare The Secret of Monkey Island feiert seinen 30. Geburtstag. Golem.de hat einen neuen Durchgang gewagt - und wüst geschimpft.
Von Benedikt Plass-Fleßenkämper