0d053 – Scum with Scrum

In der heutigen Folge versuchen Sven und Stefan mal Scrum zu erklären und ein wenig den Nebel zu lüften, welcher sich um dieses Thema oftmals legt.
Die Datenverluste sind aufgrund der langen Zeit seit der letzten Folge ein wenig mehr als sonst, was dem Spaß jedoch keinen Abbruch tut.

Datenverluste 

News

Thema:  Scum with Scrum

Wikipedia: Scrum, Podcast von Toby Baier: Agiles Produktmanagement, a funny Scrum Master movie with Jeff Sutherland

Aufgenommen am: 17.12.2019
Veröffentlicht am: 18.12.10.2019
Intro & Outro Chiptune  CC BY SA 4.0: Pumped by ROCCOW
Logo CC BY 2.0 Richard Patterson

Disclaimer

In diesem Podcast werden Techniken oder Hardware vorgestellt, die geeignet sind, externe Geräte anzugreifen. Dies geschieht ausschließlich zu Bildungszwecken, denn nur, wenn man die Angriffstechniken kennt, kann man sich effektiv davor schützen. Denkt immer daran, diese Techniken oder Hardware nur bei Geräten anzuwenden, deren Eigner oder Nutzer das erlaubt haben.Der unerlaubte Zugriff auf fremde Infrastruktur ist strafbar (In Deutschland §202a, §202b, §202c StGB).

3 Gedanken zu „0d053 – Scum with Scrum

  1. rince

    Ihr habt nicht nur einen Hörer in Stuttgart 🙂 wart Ihr schonmal beim Stammtisch des CCCS? Das könnte sich lohnen, zumindest der im Lichtblick

    Gruß, Rince

    Antworten
  2. Deus Figendi

    Haha, ich nähere mich der aktuellen Episode,

    bzw. “Salt direkt neben das Passwort speichern” sei Quatsch (bei ca. 0:43):
    Ich denke das stimmt nicht. Vielleicht besteht hier ein Missverständnis über den Zweck des Salzes: Es geht darum Regenbogentabellen nutzlos zu machen. Ich vermute ihr wisst was Regenbogentabellen sind, aber für alle anderen: Das sind Tabellen/Datenbanken, die vorab die geläufigsten Passwörter (password123, admin, password, qwerty …) ihren hashes zuordnen

    7576f3a00f6de47b0c72c5baf2d505b0 = password123
    456b7016a916a4b178dd72b947c152b7 = admin
    286755fad04869ca523320acce0dc6a4 = password
    a86850deb2742ec3cb41518e26aa2d89 = querty

    Wenn man nun so eine Datenbank erbeutet und findet dort gehashte Passwörter OHNE SALZ, kann man einfach gucken ob man identische Hashes in seiner Regenbogentabelle hat und zack weiß man der User hat “passwort123” und der User hat “querty” und der User da, den hash kenne ich nicht, der wohl nicht eines der 1.000.000 häufigsten Passwörter.

    Wenn man die Passwörter jetzt salzt und das Salz direkt neben das Passwort in die gleiche Tabelle schreibt, aber natürlich für jedes Passwort ein eigenes Salz generiert, dann erhöht das die Kosten für den Angreifer ungemein, denn theoretisch bräuchte er jetzt für jeden User seine eigene Regenbogentabelle nämlich mit allen Standardpasswörtern+Salz.

    Also Salz was in der Datenbank mit drin steht ist absolut sinnvoll und erhöht die Kosten für den Angreifer ERHEBLICH, er muss nämlich dann jedes Passwort einzeln bruteforcen.

    In der Regel ist es aber gar nicht notwendig das Salz neben das Passwort zu speichern, weil im Grunde jeder String der für die Datenbank einigermaßen unique ist taugt, z.B. die Email-Adresse oder der Hash der Emailadresse oder der Benutzername und das Registrierungsdatum oder oder oder.

    Man kann jetzt freilich noch zusätzlich ein Geheimnis hinzufügen, welches man nicht verliert wenn man die Datenbank verliert, aber das ist dann oft nicht einzigartig jeh Passwort.

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.