IT Security #18 - How passwords are stored

[@t3chr0b0t2]

Für deine Theorie Playlist hätte ich noch Vorschläge die ich mir Wünschen würde: Betriebssysteme Technische Informatik Programmierparadigmen

[@mndnf]

T3CH R0B0T Betriebssysteme würde mich auch interessieren :D

[@TheMorpheusTutorials]

Jap, hab ich auch alles irgendwo geplant, aber ich glaub, du kennst meinen Plan, der ist riesig :D

[@boss47g]

Wie sieht ein starkes Passwort aus? Kannst du dein KZbin Passwort als Beispiel nennen?

[@TheMorpheusTutorials]

Klar, also mein KZbin Passwort ist absolut sicher und lautet Ich_Bin#Anonymous11elf! :D

[@boss47g]

The Morpheus Tutorials Cool. Meins ist QWERTZ

[@TheInnerPigdog]

Früher nahm ich immer gern abc123, aber irgendwann musste man mindestens 8 Zeichen verwenden mit Sonderzeichen... Deswegen: abcd123!

[@HeyImYannick]

Nice! :)

[@manolol1281]

Warum guten Morgen? Ich gucke das am Abend xD

[@dnhausdermode3744]

Hey Morpheus wo werden Passwörter von Programmen gespeichert? Ich versuch die ganze Zeit das Passwort von dem Programm ausfindig zu machen oder zumindest wo sich die Datei befindet. Wie mach ich das ?

[@TheMorpheusTutorials]

Im Bestenfall gar nicht, sondern auf nem Server

[@e1nste1in]

Wird der Salt dann in der Praxis separat gespeichert oder in der gleichen Tabelle?

[@TheMorpheusTutorials]

in derselben Tabelle meist

[@TheInnerPigdog]

Der Hashwert von Passwort bleibt immer der selbe? Kommt das nicht auf die Anzahl der Runden an? Der Hashwert von Passwort nach 6 Runden ist ein anderer Wert wie nach 30 Runden.

[@dontbetoxic4387]

Ja

[@paul300]

Kannst du bitte mal ein Video zu Bcrypt machen, einfach als beispiel für einen Verschlüsselungs-Algorythmus und ihn dann so ein bischen erklären

[@saschavloggt6232]

Als Salt würde ich bei sowas nen Wert nehmen, der sowieso in der Datenbank steht, aber nicht direkt darauf rückschließen lässt, dass das der Salt sein soll. Stellen wir uns doch mal so ne User-Table vor: Benutzername | E-Mail | Passwort | ( Und von mir aus noch ein Registriert seit als UNIX TImestamp ) Irgendeinen Wert davon, also entweder den Benutzername, die Mailaddy oder den Timestamp würde ich eine Runde durch brypt() jagen und das, was dabei als Rechenergebnis rauskommt, als Salt nutzen, um das Passwort zu errechnen. :-)

[@TheMorpheusTutorials]

Wichtig ist aber, dass der Salt wirklich zufällig ist, sonst kann man ja wieder Rainbowtables erstellen. Daher eigenen sich Name, Mailadresse und Timestamp nicht wirklich dafür.

[@pythoncake2708]

Rsa und den private key löschen. Dann muss der Angreifer auch erstmal daran kommen. Den ne auf die Datenbank legen sondern anderswo wo nur das back-end Zugriff hat und dann kann der angreifer mit den Daten auch nix anfangen

[@Shulkerkiste]

Einer Sache konnte ich nicht ganz folgen. Wenn der böse Mann das "PASSWORT" weiß und den dazugehörigen Salt, kann er das dann nicht einfach selber hashen und dann einfach den Salt am Ende wieder dranhängen, wie im Video? Ich verstehe nicht ganz, warum man das Passwort nicht rausbekommt, wenn man auch den Salt hat.

[@Garpsta]

wenn man das passwort kennt muss man eh nichtmehr salten und hashen. salt schuetzt vor vorgefertigten rainbow-tables und hat auch den grossen vorteil das identische passwoerter nicht den selben hash wert ergeben bzw hash werte kollidieren

[@Shulkerkiste]

Ahh jetzt hab ich's verstanden, vielen Dank :D

[@TheMorpheusTutorials]

danke @Jack Frost :)

[@gcanary562]

The Morpheus Tutorials Und am Ender muss man das Zeug Peppern 😇

[@Garpsta]

wird nicht schon seit laengerem vom peppern abgeraten? neben theoretischen problemen (hash im hash, 'complexity is the enemy of security') und problemen wie wartung? oder gibt es schon nen algo der das pepper konzept behandelt? ansonsten wuerde ja auch vom bruder schneier gelten: never roll your own crypto