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

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

  1. Thema

Neues Thema Ansicht wechseln


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

    Autor: SJ 10.09.18 - 11:36

    Nebst dem, dass ein Passwort im Klartext ein absolutes No-Go ist, reicht es nicht aus, wenn ein Passwort nur gehasht wird. Es muss auch noch ein Salt dabei sein und am besten für jeden Benutzer ein anderes Salt.

    Und wie immer:

    Man sollte ein Passwort keine zweimal verwenden. Deswegen einen lokalen Passwortmanager verwenden, wo man unterschiedliche Passwörter generieren kann in der jeweils zulässigen höchsten Länge und wenn möglich mit Gross-/Kleinbuchstaben, Ziffern und Sonderzeichen.

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

  2. Re: Und Passwörter sollten nicht nur...

    Autor: TrollNo1 10.09.18 - 11:39

    Richtig, denn Hashes bringen so gesehen gar nichts ohne Salt. hat sich auch noch nicht überall rumgesprochen. Ein Rainbow Table macht einen Hash zum Hai ohne Zähne.

    Menschen, die mich im Internet siezen, sind mir suspekt.

  3. Re: Und Passwörter sollten nicht nur...

    Autor: olleIcke 10.09.18 - 12:06

    Moment mal! Nur Nix bringt nix!
    Hashes sind auf jeden Fall weitaus besser als nur die 1 zu 1 Strings!

    1. kann man aus ihnen nicht ohne weiteres das Passwort lesen
    2. direkte Rückumwandlung ist nahezu ausgeschlossen
    3. MUSS man einen Rainbow-table-Abgleich machen um zum original Passwort zu kommen.
    4. bringt auch das nur etwas wenn dein Passwort bereits ein relativ schwaches ist.

    Also konkret: Die hashes der Passwörter "12345" und "Passwort" sind auf jeden Fall in den billigsten Rainbow-tables zu finden. Aber wenn man wie erwähnt bereits nen Passwortmanager benutzt und sich Passwörter generieren lässt die bereits wie hashes aussehen, dann ist man einigermaßen sicher.

    Ich weiß es jetzt auch nicht genau bei wieviel byte Passwort der Rainboxtable wie groß sein "muss" aber ich vermute mal, dass man zB ... pfff "9B0966w4368e1ed185000mK164dbe071" einfach gehasht nichmal in nem table findet der so Google-Rechenzentrum-Speicherplatz verschlingt.

    That being said: Natürlich sollte man immer soviele Punkte wie möglich abdecken:
    user:
    * lokalen Passwortmanager
    * lange generierte Passwörter
    * nie das selbe Passwort bei verschiedenen Services
    * 2 factor auth nutzen
    provider:
    * hashen
    * salten
    * 1000x most used words/passwords verbieten
    * 2 factor auth anbieten

    Das golem-Forum kann BBCode!

  4. Re: Und Passwörter sollten nicht nur...

    Autor: SJ 10.09.18 - 12:11

    olleIcke schrieb:
    --------------------------------------------------------------------------------
    > 3. MUSS man einen Rainbow-table-Abgleich machen um zum original Passwort zu
    > kommen.
    > 4. bringt auch das nur etwas wenn dein Passwort bereits ein relativ
    > schwaches ist.

    Ich glaube du hast nicht begriffen, was Rainbow Tables sind.

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

  5. Re: Und Passwörter sollten nicht nur...

    Autor: olleIcke 10.09.18 - 12:31

    SJ schrieb:
    --------------------------------------------------------------------------------
    > Ich glaube du hast nicht begriffen, was Rainbow Tables sind.

    .. mmmhh fast! also ich hab mich tatsächlich noch nie damit beschäftigt. Also gabs den Versuch es mir begreiflich zu machen noch gar nicht. Nun hab ich aber nachgeschlagen und sehe, dass ich fast Recht damit hatte, dass es ne Aaaaart-hash-Look-Up-table is.

    War das jetzt der einzige Vorwurf? Sag mir doch mal was konkretes.

  6. Re: Und Passwörter sollten nicht nur...

    Autor: dura 10.09.18 - 12:37

    SJ schrieb:
    --------------------------------------------------------------------------------
    > olleIcke schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > 3. MUSS man einen Rainbow-table-Abgleich machen um zum original Passwort
    > zu
    > > kommen.
    > > 4. bringt auch das nur etwas wenn dein Passwort bereits ein relativ
    > > schwaches ist.
    >
    > Ich glaube du hast nicht begriffen, was Rainbow Tables sind.

    Ähm, bist du sicher, dass DU es verstanden hast?
    Natürlich muss das Passwort irgendwie da rein kommen und da gibt's entweder Wordlists oder Brute-Force. Einmal muss man das in passender Zeit erzeugen und dann noch speichern. Zumindest für den Heimgebrauch kommt man da nicht weit über 10 Chars, vor allem nicht mit Sonderzeichen. NSA und Co. sind da (sehr) vermutlich weiter.

  7. Re: Und Passwörter sollten nicht nur...

    Autor: andy01q 10.09.18 - 13:39

    Bei Rainbow-Tables sollte auch beachtet werden, dass die Hashes nicht unendlich lang sind.
    D.h. wenn ich "sd98g709w8n7r983N/?WE()MR/=)WU§(R=´samud" Als PW verwende, dann findet die Rainbow-Table evtl. ein sehr viel einfacheres, das eine Kollision darstellt.
    Aktuell sind die Rainbow-Tables noch nicht lang genug, dass Kollisionen wahrscheinlich sind, aber das kann noch kommen.

  8. Re: Und Passwörter sollten nicht nur...

    Autor: PhilippK 10.09.18 - 14:34

    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.

  9. Re: Und Passwörter sollten nicht nur...

    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.

  10. Re: Und Passwörter sollten nicht nur...

    Autor: PhilippK 10.09.18 - 12:52

    Ich vertrete ebenfalls die These, dass nur "schwache" Passwörter Opfer von RT-Angriffen werden können. Hier muss man jedoch "schwach" definieren. Und das ist für mich simpel ein nicht-zufälliges Passwort. "CorrectHorseBatteryStaple" wäre vielleicht durch einfaches Brute-Forcing nicht leicht zu knacken. Hat man aber eine RT mit Kombinationen englischer Wörter bis zu einer bestimmten länge, ist es trivial zu knacken.

    Wie wahrscheinlich ist es jedoch, dass ein zufälliges Passwort wie "aR95M5@g&ei0" in der RT enthalten ist?

    Gehen wir davon aus, dass der Anbieter die Buchstaben a-zA-Z, Zahlen 0-9 sowie acht verschiedene Sonderzeichen erlaubt. Die Passwortlänge ist auf genau zwölf Zeichen begrenzt.

    Möchtest du nun genau ein zufällig generiertes Passwort aus diesem Ergebnisraum herausfinden, beträgt die Chance dafür pro Passwort 1 / (70^12).

    Speicherst du nun alle 12-stelligen zufälligen Passwörter (je 12 Byte) mit ihrem Hashwert (bspw. je 20 Byte) mit Trennzeichen (2 Byte) auf Festplatten, so brauchst du etwa 470 Zetabyte Speicher dafür. Bei einem Gigabytepreis von 2 Cent entspricht das Festplatten im Wert von 9,4 Billionen (((editiert von Trillionen))) Euro. Zusätzlich noch Controller und Kabel sowie laufende Kosten.

    Daher bleibe ich der Ansicht, dass ein RT-Angriff nur gegen schwache Passwörter funktioniert. Sie wird niemals alle zufälligen Passwörter enthalten können. Salten und starke Algorithmen verwenden sollte man trotzdem aus bereits genannten Gründen.



    1 mal bearbeitet, zuletzt am 10.09.18 13:10 durch PhilippK.

  11. Re: Und Passwörter sollten nicht nur...

    Autor: TrollNo1 10.09.18 - 13:16

    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.

    Menschen, die mich im Internet siezen, sind mir suspekt.

  12. Re: Und Passwörter sollten nicht nur...

    Autor: PhilippK 10.09.18 - 13:27

    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.

    Danke für den Kommentar, hatte die Definition einer RT nicht vor Augen. Wenn du so eine Tabelle aufbauen möchtest, wird es allerdings noch lustiger.

    160-bit Hash -> 2^160 verschiedene Hashes. Allein jeden davon zu speichern, ohne das zugehörige Passwort, wären (mit 1 Byte Trennzeichen) etwa 3 x 10^28 Zettabyte. Also einige Ordnungsgrößen mehr als die ganzen Passwörter. Daher ein noch unrealistischeres Szenario.

  13. Re: Und Passwörter sollten nicht nur...

    Autor: Renegard 10.09.18 - 14:31

    man kann diese Tabellen fast beliebig komprimieren. zum richtigen Hashausgangswert auslesen muss dann beim auslesen nur so oft gehasht werden, wie groß die komprimierung sein soll.
    wenn man die tabelle nur 1/1000 so groß haben will muss beim auslesen bis zu 1000 mal gehasht werden um den richtigen wert zu bekommen. Beim abspeichern wurde einfach ein Wert mehrfach gehasht und der Ausgangswert und der endhash gespeichert. wenn man nun einen hash hat und den ausgangswert möchte muss man diesen nur hashen, bis ein wert erscheint, der in der tabelle gespeichert ist.
    dann hat man den ausgangswert um mit "1000 - 1 - Anzahl wie oft gehasht wurde um den wert zu finden" hashungen(?) den Ausgangswert für den echten Hash zu erhalten.
    Das funktioniert auch mit Milliarden usw.
    da ich aus dem thema schon fast 10 jahre raus bin und nur noch alte unterlagen hier habe habe ich aber auch nichts genaues mehr hier.

  14. Re: Und Passwörter sollten nicht nur...

    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?

  15. Re: Und Passwörter sollten nicht nur...

    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.

  16. Re: Und Passwörter sollten nicht nur...

    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.

  17. Re: Und Passwörter sollten nicht nur...

    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...

    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? ;)

  19. Re: Und Passwörter sollten nicht nur...

    Autor: 1nformatik 10.09.18 - 12:14

    Hash plus Salt ja aber es kommt auch auf den Algorithmus an, am besten bcrypt mit hohem Coast Factor statt einfach nur sha256 oder ähnliches.

  20. Re: Und Passwörter sollten nicht nur...

    Autor: Quantium40 10.09.18 - 13:52

    1nformatik schrieb:
    > Hash plus Salt ja aber es kommt auch auf den Algorithmus an, am besten
    > bcrypt mit hohem Coast Factor statt einfach nur sha256 oder ähnliches.

    Bei x Usern und einer Passwortfilterung in Chatnachrichten, ist das möglicherweise keine gute Idee mehr. Rechenleistung auf Serverseite gibt es ja nicht geschenkt.

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

    Autor: SJ 10.09.18 - 13:55

    Da filterst du zuerst mal raus.

    Machste eine Passwortrichtline von min. 8 Zeichen - dann fallen sehr viele Wörter schon mal raus.

    Dann enthält die Richtlinie noch dass Gross- und Kleinbuchstaben enthalten sein müssen sowie Zahlen. Dann gibts kaum noch etwas, was gehashed werden muss in einem normalen Chat.

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

  22. LOLcul8r

    Autor: Missingno. 10.09.18 - 13:57

    SJ schrieb:
    --------------------------------------------------------------------------------
    > Da filterst du zuerst mal raus.
    >
    > Machste eine Passwortrichtline von min. 8 Zeichen - dann fallen sehr viele
    > Wörter schon mal raus.
    >
    > Dann enthält die Richtlinie noch dass Gross- und Kleinbuchstaben enthalten
    > sein müssen sowie Zahlen. Dann gibts kaum noch etwas, was gehashed werden
    > muss in einem normalen Chat.
    ;-)

    --
    Dare to be stupid!

  23. Re: Und Passwörter sollten nicht nur...

    Autor: Quantium40 10.09.18 - 13:31

    SJ schrieb:
    > Nebst dem, dass ein Passwort im Klartext ein absolutes No-Go ist, reicht es
    > nicht aus, wenn ein Passwort nur gehasht wird. Es muss auch noch ein Salt
    > dabei sein und am besten für jeden Benutzer ein anderes Salt.

    Wenn man für alle Benutzer das selbe Salt benutzt, kann man es auch gleich bleiben lassen.

  24. Re: Und Passwörter sollten nicht nur...

    Autor: PhilippK 10.09.18 - 13:35

    Quantium40 schrieb:
    --------------------------------------------------------------------------------
    > SJ schrieb:
    > > Nebst dem, dass ein Passwort im Klartext ein absolutes No-Go ist, reicht
    > es
    > > nicht aus, wenn ein Passwort nur gehasht wird. Es muss auch noch ein
    > Salt
    > > dabei sein und am besten für jeden Benutzer ein anderes Salt.
    >
    > Wenn man für alle Benutzer das selbe Salt benutzt, kann man es auch gleich
    > bleiben lassen.

    Das stimmt so auch nicht. Dank des Salts lässt sich die geleakte Datenbank wenigstens nicht mit einer anderen, die denselben Hashalgorithmus nutzt, abgleichen.

  25. Re: Und Passwörter sollten nicht nur...

    Autor: Quantium40 10.09.18 - 13:47

    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.

  26. Re: Und Passwörter sollten nicht nur...

    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... :-)

  27. Re: Und Passwörter sollten nicht nur...

    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.

  28. Re: Und Passwörter sollten nicht nur...

    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?

  29. Re: Und Passwörter sollten nicht nur...

    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.

  30. Re: Und Passwörter sollten nicht nur...

    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.

  31. Re: Und Passwörter sollten nicht nur...

    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.

  32. Re: Und Passwörter sollten nicht nur...

    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?

  33. Re: Und Passwörter sollten nicht nur...

    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.

  34. Re: Und Passwörter sollten nicht nur...

    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.

  35. Re: Und Passwörter sollten nicht nur...

    Autor: Phantom 10.09.18 - 21:46

    Kennt ihr einen guten und vertrauenswürdigen Passwort Manager?

    .



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

  36. Re: Und Passwörter sollten nicht nur...

    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

  37. Re: Und Passwörter sollten nicht nur...

    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.

  38. Re: Und Passwörter sollten nicht nur...

    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.

  39. Passwörter selbst sind das eigentliche...

    Autor: Der Agent 10.09.18 - 13:40

    ...denn die sind seit über einem Jahrzehnt praktisch "deprecated".

    NFC-Karte mit Display + PIN on card wäre so viel einfacher & sicherer...
    Sowas in die Richtung: https://www.ubs.com/content/dam/ubs/microsites/digital/images/display-card-front-back-de3.png

    Müsste man nur mal forcieren...

  1. Thema

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. SWK-NOVATEC GmbH, Karlsruhe
  2. Volkswagen Financial Services AG, Braunschweig
  3. STRABAG PROPERTY & FACILITY SERVICES GMBH, Köln / Münster
  4. operational services GmbH & Co. KG, Dresden, Berlin, Frankfurt am Main

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (u. a. Inno3D GeForce RTX 3090 Gaming X3 für 1.724€)
  2. (u. a. Ryzen 7 5800X 469€)
  3. (u. a. Asus Dual GeForce RTX 3060 Ti für 629€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Sprachsteuerung mit Apple Music im Test: Es funktioniert zu selten gut
Sprachsteuerung mit Apple Music im Test
Es funktioniert zu selten gut

Eigentlich sollen smarte Lautsprecher den Musikkonsum auf Zuruf besonders bequem machen. Aber die Realität sieht ganz anders aus.
Ein Test von Ingo Pakalski

  1. Streaming Apple Music kommt auf Google-Lautsprecher
  2. Internetradio Apple kündigt Apple Music 1 an und bringt zwei neue Sender

Quereinsteiger: Mit dem Master in die IT
Quereinsteiger
Mit dem Master in die IT

Bachelorabsolventen von Fachhochschulen gehen überwiegend sofort in den Job. Einen Master machen sie später und dann gerne in IT. Studienangebote für Quereinsteiger gibt es immer mehr.
Ein Bericht von Peter Ilg

  1. IT-Arbeit Es geht auch ohne Chefs
  2. 42 Wolfsburg Programmieren lernen ohne Abi, Lehrer und Gebühren
  3. Betriebsräte in der Tech-Branche Freunde sein reicht manchmal nicht

20 Jahre Wikipedia: Verlässliches Wissen rettet noch nicht die Welt
20 Jahre Wikipedia
Verlässliches Wissen rettet noch nicht die Welt

Noch nie war es so einfach, per Wikipedia an enzyklopädisches Wissen zu gelangen. Doch scheint es viele Menschen gar nicht mehr zu interessieren.
Ein IMHO von Friedhelm Greis

  1. Desktop-Version Wikipedia überarbeitet "klobiges" Design