Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Pwned Passwords: Troy Hunt…

Was ist mit Salt?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Was ist mit Salt?

    Autor: Mehrtürer 22.02.18 - 20:23

    Irgendwas schein ich zu übersehen, aber wenn die Passwörter sauber gesaltet werden, dann wird ein Passwortlookup über einen bekannten Hash (also einen Hash zu dem man einen Ausgangswert kennt) schwierig und die komplette Datenbank an Hashes wird sinnlos.

    Wieso empfielt das Nist Passwörter die bekannte Hashes treffen zu verbieten, anstatt Salting zu empfehlen?!

  2. Re: Was ist mit Salt?

    Autor: Compufreak345 22.02.18 - 20:55

    Wenn ich das richtig verstehe geht es hier doch darum bereits geleakte Passwörter nicht wieder zu verwenden, um z.B. Bruteforce/Dictionary-Angriffe zu erschweren. Das hat erstmal nichts mit Lookups von Hashes zu tun, das wäre ein anderes Angriffsszenario für das deine Empfehlung natürlich korrekt ist.

  3. Re: Was ist mit Salt?

    Autor: dbenzhuser 22.02.18 - 20:56

    Da wurden die geleakten Klartext-Passwörter gesammelt und gehasht. Wenn sich jetzt ein neuer Nutzer bei meinem Dienst anmelde kann ich das Passwort nehmen, SHA1-Hash berechnen und mit der Liste abgleichen.

    Wenns dort vorkommt sag ich dem Nutzer er soll sich was anderes ausdenken.

    Wenns nicht in der Liste ist, hashe ich es für meine Datenbank mit einer für Passwörter gedachten Funktion (also nicht SHA1, egal ob mit Salt oder ohne) und erlaube die Registrierung.

  4. Re: Was ist mit Salt?

    Autor: corruption 22.02.18 - 21:00

    Weil ein Salt mit in der Datenbank steht. Wenn diese geklaut wird muss man dann die Tabelle neu generieren (Passwort+Salt) dies macht man natürlich erst für die Passwörter, die häufig vorkommen....

    Beispiel: Person x klaut Datenbank, Datenbank enthält 200 Passworthashes und 200 Salt Werte. Person x hasht nun selbst alle bekannten Standardpasswörter wie 123456 mit dem jeweiligen Salt der in der Datenbank steht. -> Schnell gemacht, auch für 200 Einträge kann ich 123456 schnell prüfen. Wenn es hingegen ein 16 Stellen Passwort mit hoher Entopie ist muss Person x für jeden Hasheintrag! eine komplette Bruteforce-Attacke durchführen. Der Salt ist also ausschließlich dazu da, dass der Aufwand für Rainbowtable-Angriffe immer zur Folge hat, dass man alles neu generieren muss. Dies geht bei sehr einfachen und bekannten Passwörtern aber immer noch sehr schnell.

  5. Re: Was ist mit Salt?

    Autor: Mehrtürer 22.02.18 - 21:36

    Ah sorry. Jetzt hab ich den Artikel zum ersten Mal richtig verstanden.
    Jetzt lässt sich natürlich noch darüber streiten ob man nicht die Passwörter direkt im Klartext veröffentlichen sollte. Dann könnte man sehr viel schneller erkennen, welche Passwörter jetzt unsicher sind und welche Kombinationen aus "Wörtern" damit jetzt auch eher unsicherer geworden sind.

    Ich bin immer ein Fan davon Information die Jemand hat, und vor allem Information von der man weiß dass ein potentieller Angreifer sie hat, einfach jedem voll zugänglich gemacht werden sollte.

    So müsste ich ja ewig viel Bruteforcen um rauszufinden was diese halbe Milliarde Passwörter in der Tabelle sind.

  6. Re: Was ist mit Salt?

    Autor: Hugie 22.02.18 - 21:54

    Mehrtürer schrieb:
    --------------------------------------------------------------------------------
    > Jetzt lässt sich natürlich noch darüber streiten ob man nicht die
    > Passwörter direkt im Klartext veröffentlichen sollte. Dann könnte man sehr
    > viel schneller erkennen, welche Passwörter jetzt unsicher sind und welche
    > Kombinationen aus "Wörtern" damit jetzt auch eher unsicherer geworden
    > sind.
    >
    > Ich bin immer ein Fan davon Information die Jemand hat, und vor allem
    > Information von der man weiß dass ein potentieller Angreifer sie hat,
    > einfach jedem voll zugänglich gemacht werden sollte.
    >
    > So müsste ich ja ewig viel Bruteforcen um rauszufinden was diese halbe
    > Milliarde Passwörter in der Tabelle sind.

    Und exakt das müssen dann auch die Bösewichte machen, die sich dank dieser Daten einen optimalen Dictionary Angriff vorbereiten wollen.
    Das berechnen einzelner SHA1 Hashs zum sicherheitstest ist wirklich vernachlässigbar.

    Deinen Gegnern, Skriptkiddies, Sonntagsbösewichten, aber gleich alle verfügbaren Daten - fertig gesammelt und kostenfrei - hinzustellen, wäre wirklich fahrlässig.

    Man nehme einen frisch gehackten Service, der Semi-sauber seine passwörter nur als SHA1 verschlüsselt hat.
    Mit den originalen kannst du dir "sofort" orig:hash kombis basteln und dich frei einloggen. Hast du nur die hashes kommst du nicht sofort an alle accounts ran, da du ja weiterhin das original brauchst. Und eine kollision berechnet sich auch nicht mal so eben mit links.

    Weiter kannst du auch mit einer geleakten Salt:Hash datenbank und den originalen dank des gegebenen salts auch in planbarer Zeit dict angriffe fahren.

    Mit den Originalen würde also die Menge an Angriffen imho sehr schnell zunehmen.
    Zu riskant.

  7. Re: Was ist mit Salt?

    Autor: mambokurt 22.02.18 - 21:57

    Das ist ja der Sinn dahinter, wenn er die Passwörter im Klartext verbreitet nimmt sich jedes Skriptkiddi die drölfmillionen Passwörter und lässt die gegen Websites laufen. So wie es jetzt ist muss man die pw erst bruteforcen um sie zweckzuentfremden kann sie aber ad hoc zum Abgleich benutzen.



    1 mal bearbeitet, zuletzt am 22.02.18 21:57 durch mambokurt.

  8. Re: Was ist mit Salt?

    Autor: corruption 22.02.18 - 22:34

    @Hugie

    Grundsätzlich richtig was du schreibst, ganz klar! ;-)

    Eine Anmerkung: "...nur als SHA1 verschlüsselt hat..."
    Hashen != Verschlüsselung, es handelt sich um eine mathematische Einwegfunktion. Das hat mit Verschlüsselung nichts zutun!

    Ich denke du weißt das, aber den Kommentar konnte ich mir nicht verkneifen ;-)

    Edit:
    Das API von denen ist ja echt cool, da kann man dann per HTTP GET ein PW-SHA1-Hash hinschicken und bekommt direkt eine Anzahl, wie oft dieses Passwort schon verwendet wurde zurück.... Super praktisch um tatsächlich so eine Prüfung in eine produktive Website einzubauen....

    123456 in SHA-1 ist "7c4a8d09ca3762af61e59520943dc26494f8941b" die API liefert mit folgendem GET-Request: https://api.pwnedpasswords.com/pwnedpassword/7c4a8d09ca3762af61e59520943dc26494f8941b

    Die Anzahl zurück: 20760336

    --> Passwort als Betreiber verbieten, da zu sehr verbreitet.


    Was auch richtig geil ist:

    $ echo -n "correcthorsebatterystaple" | sha1sum
    bfd3617727eab0e800e62a776c76381defbc4145 -
    $ curl https://api.pwnedpasswords.com/pwnedpassword/bfd3617727eab0e800e62a776c76381defbc4145
    103



    3 mal bearbeitet, zuletzt am 22.02.18 22:43 durch corruption.

  9. Re: Was ist mit Salt?

    Autor: Hugie 22.02.18 - 22:52

    corruption schrieb:
    --------------------------------------------------------------------------------
    > @Hugie
    >
    > Grundsätzlich richtig was du schreibst, ganz klar! ;-)
    >
    > Eine Anmerkung: "...nur als SHA1 verschlüsselt hat..."
    > Hashen != Verschlüsselung, es handelt sich um eine mathematische
    > Einwegfunktion. Das hat mit Verschlüsselung nichts zutun!
    >
    > Ich denke du weißt das, aber den Kommentar konnte ich mir nicht verkneifen
    > ;-)

    Jap, weiß ich ;) Ist schon spät :P
    Aber ich hätte vermutlich einen ähnlichen Kommentar verfasst :P

    btw, wer einen Win AD betreibt und überlegt, wie er dort nach hashes testen kann, kann der anleitung hier folgen:
    https://amarkulo.com/integrating-database-of-pwned-password-hashes-with-microsoft-ad/

    Habe es selber noch nicht probiert, werde es aber mal in unserer Firma vorschlagen.

  10. Re: Was ist mit Salt?

    Autor: maverick1977 23.02.18 - 00:47

    corruption schrieb:
    --------------------------------------------------------------------------------
    > Beispiel: Person x klaut Datenbank, Datenbank enthält 200 Passworthashes
    > und 200 Salt Werte.

    Falsch! Das Salz ist im Passworthash mit drin!

    Einfach erklärt in einer Sprache die ich beherrsche: PHP

    $passworthash = sha256($salt1 . $eingabe . $salt2);

    Ausgegeben wird ein einziger Hash. Salz+Pass+Salz = Hash. Und das Salz steht in keiner Datenbank (da gehört es auch nicht hin!), sondern in einem Script bzw. wird von einer anderen Quelle nachgeladen. Würde das Salz irgendwo in der Datenbank herum geistern, würde ein einfacher Angriff auf die Datenbank bereits ausreichen. Packt man es in ein Script oder lädt es von einer anderen Quelle nach, braucht man einen zweiten Angriffsweg, nämlich direkt per SSH oder lokal auf den Server um die Verzeichnisstruktur des Dienstes finden zu können.

  11. Re: Was ist mit Salt?

    Autor: Pecos 23.02.18 - 01:06

    Du hast offenbar den Sinn von Salts nicht verstanden.
    Der Sinn ist nämlich einfach der, dass keine Rainbowtable eingesetzt werden kann, bzw. ein Bruteforceangriff gegen mehrere Passwörter gleichzeitig gefahren werden kann.
    Der Salt ist für jeden Passwort-Hash unterschiedlich und somit muss jedes Passwort einzeln gebrutet werden.
    Hierbei ist es egal ob der Angreifer die passenden Salts kennt.

    Wie willst Du die Salts denn eigentlich in ein Skript packen? Entweder erweitert sich das Skript mit jedem neuen Passwort selbst (aua), oder das Salz ist hartkodiert im Code und für jeden Hash gleich (noch mehr aua) und somit unwirksam.

    Siehe auch: https://de.wikipedia.org/wiki/Salt_(Kryptologie)#Motivation

  12. Re: Was ist mit Salt?

    Autor: corruption 23.02.18 - 01:20

    Eig gibt es zu Pecos Post nichts mehr hinzuzufügen. Danke dafür! ;-)

    Ich habe dennoch ein wenig Lernmaterial:

    Was du vorschlägst geht schon in die Richtung Security through obscurity ( https://en.wikipedia.org/wiki/Security_through_obscurity ) Nur weil du versuchst den Salt zu verstecken, wird es nicht besser. Den kannst du einfach mit in die Datenbank schreiben, weil du dadurch wie von Pecos erwähnt, nur das Ziel verfolgst die Rainbowtable-Angriffe / Wörterbuchangriffe / Brute-Force-Angriffe zu erschweren.

    Außerdem hoffe ich, dass du, in deiner Anwendung für jedes Passwort einen eigenen Salt hast und nicht für deine ganze Datenbank mit vielen Nutzern nur ein fixen Salt in einem Script hinterlegt hast. Das würde die Sicherheit der User verringern. ( Ich generiere mit diesem Salt die Rainbowtable und kann alle Nutzerdaten knacken, wenn jeder Nutzer ein Salt hat muss für jedes Hash+Salt-Paar diese Tabelle erst aufgebaut werden!!! Hart im Script 1-2 Salts zu hinterlegen wäre also deutlich schlechter, wenn nicht sogar katastrophal bei einem Leak! Wie Pecos so schön gesagt hat AUA )

    Ggf ist für dich auch das Kerckhoffs’ Prinzip noch nicht geläufig:
    https://de.wikipedia.org/wiki/Kerckhoffs’_Prinzip

    Und natürlich der Link von Pecos!



    12 mal bearbeitet, zuletzt am 23.02.18 01:40 durch corruption.

  13. Re: Was ist mit Salt?

    Autor: 946ben 23.02.18 - 02:04

    maverick1977 schrieb:
    --------------------------------------------------------------------------------
    > corruption schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Beispiel: Person x klaut Datenbank, Datenbank enthält 200 Passworthashes
    > > und 200 Salt Werte.
    >
    > Falsch! Das Salz ist im Passworthash mit drin!
    >
    > Einfach erklärt in einer Sprache die ich beherrsche: PHP
    >
    > $passworthash = sha256($salt1 . $eingabe . $salt2);
    >
    > Ausgegeben wird ein einziger Hash. Salz+Pass+Salz = Hash. Und das Salz
    > steht in keiner Datenbank (da gehört es auch nicht hin!), sondern in einem
    > Script bzw. wird von einer anderen Quelle nachgeladen. Würde das Salz
    > irgendwo in der Datenbank herum geistern, würde ein einfacher Angriff auf
    > die Datenbank bereits ausreichen. Packt man es in ein Script oder lädt es
    > von einer anderen Quelle nach, braucht man einen zweiten Angriffsweg,
    > nämlich direkt per SSH oder lokal auf den Server um die Verzeichnisstruktur
    > des Dienstes finden zu können.


    Looooooooooooool

  14. Re: Was ist mit Salt?

    Autor: Anonymer Nutzer 23.02.18 - 04:58

    corruption schrieb:
    --------------------------------------------------------------------------------
    > Hart im Script 1-2 Salts zu hinterlegen wäre also deutlich schlechter, wenn
    > nicht sogar katastrophal bei einem Leak! Wie Pecos so schön gesagt hat AUA
    Am besten macht man beides!
    $individual_salt + $password + $general_salt
    Dann könnte ein Angreifer mit der DB allein nämlich garnichtsmehr anfangen und bräuchte selbst für Bruteforce-Angriffe noch den generellen Salt der irgendwo im Script steht.
    Am besten auch verschachtelt hashen SHAx($individual_salt + SHAx($password + Email/Benutzername + $general_salt)) oder schlicht mehrfach hashen. Den Server belastet das nur minimal da das Kennwort i.d.R. nur beim Verbindungsaufbau verarbeitet wird und anschließend mit Sessions gearbeitet wird. Der Aufwand beim Bruteforce wird aber mit jedem zusätzlichen hashen um den Faktor 1 vergrößert.

    Eine weitere Möglichkeit, das ganze nochmals sicherer zu machen besteht darin, den Kennworthash NICHT in der userDB zu speichern sondern ohne jegliche Zuordnung in einer extra Tabelle mit nur einer Spalte. Dafür enthält der Hash neben den oben genannten Werten noch den Benutzernamen.
    Wenn der Hash in der UserDB steht, könnte man sich auf die Adminaccounts beschränken und wenn davon dann einer 12345678 o.ä. als PW hat, kommt man so schonmal mit etwas höheren Rechten ins System und kann sich dann dort weiterhangeln.

    Durch das trennen von UserDB und pwDB aber wüßte der Angreifer nicht, welcher Kennworthash zum Admin gehört. Beim Login prüft man einfach ob in der pwDB ein Kennworthash existiert, der SHAx($individual_salt + $password + Email/Benutzername + $general_salt) entspricht. Wenn dann jemand seine Email oder den Benutzernamen ändern will, verlangt man einfach das Kennwort, löscht den alten Hash und speichert den neuen ab.

    /edit
    Das verschachteltelte hashen macht Kollisionsangriffe zudem deutlich aufwendiger da nicht "nur" eine Kollision gefunden werden muss sondern 2 (oder je nach Verschachtelung) zueinander passende Kollisionen.
    SHAx($salt + $password) vs. SHAx($salt + SHAx($salt + $password) + $password)
    Beim ersten muss man "nur" ein Passwort finden, welches mit dem Salt den Hash ergibt. Beim zweiten muss man aber ein Kennwort finden, dessen gehashter Wert mit dem gleichen Passwort erneut gehasht den Hash ergeben muss.



    1 mal bearbeitet, zuletzt am 23.02.18 05:08 durch DAUVersteher.

  15. Re: Was ist mit Salt?

    Autor: Anonymer Nutzer 23.02.18 - 05:41

    Was die Leute hier so von sich geben ist witzig. Eine Kollision ist eine Kollision, scheiß egal ob 10000000x gehasht oder einmal. Sobald ich eine Kollision zu dem final hash hab, hab ich den hash geknackt.

    Die Idee mit 2 salt und einem ausm Script ist OK, kann man machen. Den salt in anderen Datenbanken oder ähnlichem zu verstecken ist wohl eher obscurity und nicht wirklich hilfreich.

    Sicheres hashing momentan ist: ein hash pro pw. Und hoher zeitfaktor zum hashen, dh genügend rounds. Mehr Aufwand würde ich mir auch garnicht machen, ausser man wird explizit dafür bezahlt.

  16. Re: Was ist mit Salt?

    Autor: matzems 23.02.18 - 06:14

    Der Dienst ist super. Habe gerade meine mail adressen gecheckt.bei und 1 von 3 wurde gehackt. Meine alte standardmail, dort ist wohl mein dropbox+ (alter stillgelgter) myspaceaccount geleaked. Leider buntze ich seit 20 jahren das gleiche pw.stelle nun langsam alles mittels keepass per zufalls pw um. Sehe so die einzige Chance drin.

  17. Re: Was ist mit Salt?

    Autor: minnime 23.02.18 - 08:42

    Ne Leute das stimmt so alles einfach nicht. Der Salt braucht per Definition nicht geheim zu sein, soweit klar. Es ist ggf. durchaus sinnvoll für jeden Account einen eigenen Salt zu verwenden. Ich bevorzuge es, den Nutzernamen, kombiniert mit einem einzelnen dienstspezifischen Salt zu kombinieren, also hash(salt + username + Password), das sollte reichen

  18. Re: Was ist mit Salt?

    Autor: windbeutel 23.02.18 - 09:08

    DAUVersteher schrieb:
    --------------------------------------------------------------------------------
    > [ganz viel Blödsinn]
    > ...
    > Der Aufwand beim Bruteforce wird aber mit jedem zusätzlichen hashen
    > um den Faktor 1 vergrößert.

    Lol. Das kommt in meiner All-Time-Favourite-Liste der bescheuertsten IT-Aussagen/Konstrukte auf einen der vorderen Plätze.

    P.S. Auf Platz eins steht seit Jahren unangefochten das Statement einer ehemaligen Kollegin: public static final int ZWEI = 2;

  19. Re: Was ist mit Salt?

    Autor: Cardes 23.02.18 - 09:22

    Bei Lesen könnte glatt der Eindruck entstehen dass mit dem richtigen Salz die Sicherheit steht oder fällt.
    Dabei ist die Wahl des richtigen Algorithmus entscheident, nicht der Salt.
    Wer einen auf Geschwindigkeit optimierten nutzt sollte dringend umsteigen.

    Siehe:
    https://codahale.com/how-to-safely-store-a-password/

    Mittlerweile gibt es auch andere gute Alternativen wie SHA512-Crypt (das ist NICHT SHA512 !!) oder PBKDF2-HMAC-SHA512.

    Cheers

  20. Re: Was ist mit Salt?

    Autor: corruption 23.02.18 - 10:47

    Da hast du natürlich recht.

    Ich hoffe nur, dass die Forennutzer die hier offensichtlich keine Ahnung vom Thema haben nicht an sicherheitskritischen Komponenten arbeiten. Das wäre bitter.

  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. Modis GmbH, Berlin
  2. operational services GmbH & Co. KG, Braunschweig
  3. DATAGROUP Köln GmbH, Köln
  4. Porsche Consulting GmbH, Stuttgart, Berlin, Frankfurt am Main, Hamburg, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 119,90€ + Versand (Vergleichspreis 144,61€ + Versand)
  2. 199€
  3. (aktuell u. a. AMD Ryzen Threadripper 1920X für 209,90€ statt 254,01€ im Vergleich und be...
  4. (u. a. Logitech G502 Proteus Spectrum für 39€ und Nokia 3.2 DS 16 GB für 84,99€ - Bestpreise!)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Pixel 4 im Hands on: Neue Pixel mit Dualkamera und Radar-Gesten ab 750 Euro
Pixel 4 im Hands on
Neue Pixel mit Dualkamera und Radar-Gesten ab 750 Euro

Nach zahlreichen Leaks hat Google das Pixel 4 und das Pixel 4 XL offiziell vorgestellt: Die Smartphones haben erstmals eine Dualkamera - ein Radar-Chip soll zudem die Bedienung verändern. Im Kurztest hinterlassen beide einen guten ersten Eindruck.
Ein Hands on von Tobias Költzsch

  1. Live Captions Pixel 4 blendet auf dem Gerät erzeugte Untertitel ein
  2. Google Fotos Pixel 4 kommt ohne unbegrenzten unkomprimierten Fotospeicher

Change-Management: Die Zeiten, sie, äh, ändern sich
Change-Management
Die Zeiten, sie, äh, ändern sich

Einen Change zu wollen, gehört heute zum guten Ton in der Unternehmensführung. Doch ein erzwungener Wandel in der Firmenkultur löst oft keine Probleme und schafft sogar neue.
Ein Erfahrungsbericht von Marvin Engel

  1. IT-Jobs Der Amtsschimmel wiehert jetzt agil
  2. MINT Werden Frauen überfördert?
  3. Recruiting Wenn das eigene Wachstum zur Herausforderung wird

WLAN-Kameras ausgeknipst: Wer hat die Winkekatze geklaut?
WLAN-Kameras ausgeknipst
Wer hat die Winkekatze geklaut?

Weg ist die Winkekatze - und keine unserer vier Überwachungskameras hat den Dieb gesehen. Denn WLAN-Cams von Abus, Nest, Yi Technology und Arlo lassen sich ganz einfach ausschalten.
Von Moritz Tremmel

  1. Wi-Fi 6 Router und Clients für den neuen WLAN-Standard
  2. Wi-Fi 6 und 802.11ax Was bringt der neue WLAN-Standard?
  3. Brandenburg Vodafone errichtet 1.200 kostenlose WLAN-Hotspots

  1. Streaming: Apple und Netflix aus Auktion um South Park ausgestiegen
    Streaming
    Apple und Netflix aus Auktion um South Park ausgestiegen

    Insidern zufolge könnte der Bieterwettstreit um die Streaming-Rechte der Zeichentrickserie South Park bis zu 500 Millionen US-Dollar erreichen. Netflix soll sein Angebot bereits zurückgezogen haben. Auch Apple will wohl nicht mitbieten - was am jüngsten Verbot der Sendung in China liegen soll.

  2. Google: Vorabwiderspruch bei Street View wird überprüft
    Google
    Vorabwiderspruch bei Street View wird überprüft

    Googles Street View ist in Deutschland bisher kaum verfügbar, das Bildmaterial ist veraltet und Häuser sind oft verpixelt. Grund ist der Vorabwiderspruch gegen die Anzeige von Häusern, den viele Besitzer in Anspruch nahmen. Google lässt nun prüfen, ob neue Aufnahmen ohne Vorabwiderspruch möglich sind.

  3. Datenschutz: Zahl der Behördenzugriffe auf Konten steigt
    Datenschutz
    Zahl der Behördenzugriffe auf Konten steigt

    Behörden in Deutschland haben im bisherigen Jahresverlauf häufiger auf Konten von Bürgern zugegriffen als im Vorjahreszeitraum. Dem Bundesdatenschutzbeauftragten gefällt das nicht - er fordert eine Überprüfung der rechtlichen Grundlage.


  1. 15:12

  2. 14:18

  3. 13:21

  4. 12:56

  5. 11:20

  6. 14:43

  7. 13:45

  8. 12:49