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

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. 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 gehasht werden, sondern auch noch ein Salt enthalten

    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 gehasht werden, sondern auch noch ein Salt enthalten

    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 gehasht werden, sondern auch noch ein Salt enthalten

    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 gehasht werden, sondern auch noch ein Salt enthalten

    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.

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

    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.

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

    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.

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

    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.

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

    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.

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

    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.

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

    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.

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

    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.

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

    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.

  14. Passwörter selbst sind das eigentliche Problem...

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

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

    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.

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

    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.

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

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

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

    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.

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

    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.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. DATAGROUP Köln GmbH, München
  2. M-net Telekommunikations GmbH, München
  3. WEISS automotive GmbH, Raum Offenburg
  4. Bundeskriminalamt, Wiesbaden

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 72,99€ (Release am 19. September)
  2. 149,90€
  3. 449€
  4. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


5G-Report: Nicht jedes Land braucht zur Frequenzvergabe Auktionen
5G-Report
Nicht jedes Land braucht zur Frequenzvergabe Auktionen

Die umstrittene Versteigerung von 5G-Frequenzen durch die Bundesnetzagentur ist zu Ende. Die Debatte darüber, wie Funkspektrum verteilt werden soll, geht weiter. Wir haben uns die Praxis in anderen Ländern angeschaut.
Ein Bericht von Stefan Krempl

  1. AT&T Testnutzer in 5G-Netzwerk misst 1,7 GBit/s
  2. Netzausbau Städtebund-Chef will 5G-Antennen auf Kindergärten
  3. SK Telecom Deutsche Telekom will selbst 5G-Ausrüstung entwickeln

Doom Eternal angespielt: Die nächste Ballerorgie von id macht uns fix und fertig
Doom Eternal angespielt
Die nächste Ballerorgie von id macht uns fix und fertig

E3 2019 Extrem schnelle Action plus taktische Entscheidungen, dazu geniale Grafik und eine düstere Atmosphäre: Doom Eternal hat gegenüber dem erstklassigen Vorgänger zumindest beim Anspielen noch deutlich zugelegt.

  1. Sigil John Romero setzt Doom fort

Autonomes Fahren: Per Fernsteuerung durch die Baustelle
Autonomes Fahren
Per Fernsteuerung durch die Baustelle

Was passiert, wenn autonome Autos in einer Verkehrssituation nicht mehr weiterwissen? Ein Berliner Fraunhofer-Institut hat dazu eine sehr datensparsame Fernsteuerung entwickelt. Doch es wird auch vor der Technik gewarnt.
Ein Bericht von Friedhelm Greis

  1. Autonomes Fahren Apple kauft Startup Drive.ai
  2. Neues Geschäftsfeld Huawei soll an autonomen Autos arbeiten
  3. Taxifahrzeug Volvo baut für Uber Basis eines autonomen Autos

  1. HP Elitebook 700 G6: Business-Notebooks mit zweiter AMD-Ryzen-Pro-Generation
    HP Elitebook 700 G6
    Business-Notebooks mit zweiter AMD-Ryzen-Pro-Generation

    Der Computerhersteller HP hat seine Elitebook-Generation der 700er-Serie aktualisiert. Wie gehabt, werden in dieser High-End-Serie von Geschäftskundennotebooks AMD-Prozessoren eingesetzt.

  2. Machine Learning: Google bietet vorgefertigte Umgebungen für KI-Training an
    Machine Learning
    Google bietet vorgefertigte Umgebungen für KI-Training an

    Googles Deep Learning Containers sind in der Cloud gehostete Entwicklungsumgebungen, in der Nutzer ohne viel Einrichtungsaufwand ihre Machine-Learning-Software trainieren können. Die Container schöpfen Ressourcen direkt aus der Google-Cloud mit Intel-CPUs und Nvidia-GPUs. Amazon war aber zuerst da.

  3. Spielebranche: "Katastrophe biblischen Ausmaßes für die deutsche Branche"
    Spielebranche
    "Katastrophe biblischen Ausmaßes für die deutsche Branche"

    Es ist ein Schock für Spielentwickler: Nach der gefeierten Förderung mit rund 50 Millionen Euro zeichnet sich ab, welche Summe der zuständige Bundesminister Andreas Scheuer für das Jahr 2020 bereitstellt - nichts.


  1. 12:55

  2. 12:40

  3. 12:24

  4. 12:02

  5. 11:51

  6. 11:00

  7. 10:40

  8. 10:25