0d103 – RFC103 – ein fast guter Passwort Prozess

In der heutigen Episode präsentiert Stefan einen Request for Comments (RFC), um den besten Passwort-Prozess mit allen Hörerinnen zusammen zu erstellen, den es jemals gegeben hat und geben wird. Vorweg verblüfft Stefan noch Sven mit dem „Vorintro“, welches seine grandiose kreative Ader wunderbar einfasst und Beweis, dass Stefan keine Bücher schreiben wird.

Den Ausklang machen dann noch schöne und amüsante Geschichten über ChatGPT und ihre Ambitionen die Welt durch die Beantwortung der Nutzereingaben zu übernehmen.

Kontakt:

Website: 0x0d.de  – Email: Feedback@0x0d.de (PGP) – Signal: +4916098720733
Mastodon: @zeroday@chaos.social (Sven), @zeroday@podcasts.social (Stefan) – Twitter: @Zeroday_Podcast (Stefan)

Hausmeisterei

Datenverluste 

News

Thema: RFC103 – ein fast guter Passwort Prozess

bcrypt – Wikipedia , Kryptographische Hashfunktion – Wikipedia , Datenschutz-Grundverordnung – Wikipedia , Verschlüsselung – Wikipedia , Testumgebung – Wikipedia , Informationssicherheit – Wikipedia , Privacy by design – Wikipedia , Secure by design – Wikipedia, Request for Comments – Wikipedia , Webanwendung – Wikipedia , Frontend und Backend – Wikipedia , Datenbank – Wikipedia , Passwort – Wikipedia , Salt (Kryptologie) – Wikipedia , Access token – Wikipedia , Transaktion (Informatik) – Wikipedia , Session Hijacking – Wikipedia , 0d010 – Netzneutralität & Web-Session Hijacking | Zeroday, Tokenization (data security) – Wikipedia , Advanced Encryption Standard – Wikipedia , /dev/random – Wikipedia , Trusted Platform Module – Wikipedia Gespeicherte Prozedur – Wikipedia , Achillesferse – Wikipedia

Fun and other Thinks

SUMo Software Update Monitor 

Driver Easy 

Aufgenommen am: 23.02.2023
Veröffentlicht am: 24.02.2023
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, andere Systeme 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).Unsere Aussagen spiegeln ausschließlich unsere eigene Meinung wider.

6 Gedanken zu „0d103 – RFC103 – ein fast guter Passwort Prozess

  1. Michael Schmitz

    Zufall: Da gab es (oder gibt es) doch so ne Firma, die mit der Position der Fische in einem Aquarium und einem Faktor Zufall generiert. Da würde ich schon von tatsächlichem Zufall reden. Oder? Was denkt Stefan?

    Grüße euer treuer Fan

    Micki

    Antworten
  2. Christoph Siemer

    Nachdem ich mit den RFC Teil inzwischen mehrfach angehört und, so wie auch von Sven vorgeschlagen, den Prozess skizziert hab (oder versucht), bin ich mir nicht sicher, ob ich den richtig verstanden habe. Also:

    Im Browser/JS: Passphrase P1 wird BCrypt gehasht zu P1′ (den Username lasse ich hier mal weg) und P1′ dann an den Server geschickt.

    Serverseitig wird zunächst P1′ erneut gehasht und zwar P1“ = BCrypt(P1′ || Salt), wobei das Ganze n-mal passiert für n verschiedene Salts (andernfalls müsste das Salt zum Username passend aus der DB geholt werden).
    Nun sei P1“ ein AES-Key für einen weiteren AES-Key P2, welcher zu den Userdaten in der DB passt.
    Ist das soweit tatsächlich das gemeinte Schema?
    In dem Fall hätte ich dazu folgende Fragen/Gedanken:
    1. Wozu dient das Browser-/Clientseitige Hashen? Ob man nun das Passwort oder irgendeine eindeutige Ableitung davon an den Server schickt, ändert an dem Informationsgehalt ja nichts.
    2. Der Hash P1“ (inkl Salt) steht ja in der/einer DB, um einen Abgleich zu ermöglichen, was ja analog zu gängigen Vorgehensweisen mit BCrypt-Passphrases ist. Hier würde das ja aber bedeuten, dass das „Passwort“, also der AES-Key, welcher den AES-Key P2 verschlüsselt in ebendieser DB liegt. Man könnte also mit dem Inhalt dieser DB die Userdaten entschlüsseln.
    3. Wieso ist P2 256 Zeichen lang, obwohl die Schlüssellänge von AES auf 256Bit begrenzt ist?
    4. Das Schema beruht in Teilen darauf, dass Token/Keys ausschließlich im RAM gehalten werden. Hier kann man dann das böse S-Wort in’s Spiel bringen (Skalierung), da man hier eine Session an eine bestimmte Server-Instanz festnagelt
    5. Wenn man die Email-Adresse gehasht (evt. ist sie auch Username) in der DB speichert, so kann man doch auf diese Weise den Passphrase-Reset realisieren, denn der User gibt als Reset-Request die Mailadresse an, deren Hash in der DB gesucht wird und falls gefunden, dort eine neue Passphrase (P1“) zugewiesen, da die Verschlüsselung ja wie unter 2.) beschrieben durch reines auslesen des Passphrase-Hash-Hashes ist aufgehoben werden kann.

    Wie gesagt, ich gehe fast davon aus, dass mir beim Zuhören doch etwas entgangen oder durcheinandergekommen ist, also bitte korrigiert mich. Als Vermutung hätte ich, dass Stefan eigentlich meinte, dass P1′, also quasi die Passphrase (bzw hier der erste Hash davon), die direkt vom Client kommt und deren gesalzter Hash mit der DB abgeglichen wird, als Key für den AES-Key P2 dient, wobei auch dann der Zwischenschritt P2 die Sicherheit nicht erhöht, aber eben den Wechsel der Passphrase P1 vereinfacht, weil dann nur P2 einmal neu verschlüsselt werden müsste, anstatt alle Userdaten.

    Was mir noch einfällt (Smartass-Mode on):
    – Es gibt Hardware-RNGs, die meist aus Messwerten natürlicher Prozesse (rad. Zerfall, thermodyn Prozesse, kosm. Strahlung etc) echte, ja echte Zufallszahlen in digitale Systeme speisen können
    – Sven lag schon richtig: RNGs, die auf Mausbewegungen basieren, können durchaus eine höhere Entropy aufweisen als PRNGs, das wurde bereits untersucht (e.g. DOI:10.1016/j.ins.2009.06.005)
    – Ich habe leider nicht verstanden, welchen Zweck oder gar Mehrwert es haben soll, ausnahmlos jede Variablei nach Gebrauch im Arbeitsspeicher zu „Nullen“
    – gibt es einen rationalen Grund für die Obfuscation von DB-Objektnamen? Denn wie Sven schon anmerkte, ist das für Entwickler, DBA’s und Datamanager ein echter Stock zwischen den Beinen und damit ein Fehlerrisiko, das ja einen Grund für die Abwägung braucht. Das „am Ende“ zu machen hilft nur bedingt, sofern es sich um kein One-Shot-Fire-And-Forget Projekt handelt.

    Was den Passphrase-Reset angeht, so ist’s ja wie immer: Sicher bedeutet sicher. Wenn man also Userdaten wirklich sicher verschlüsselt und das PW verlegt, dann sind die Daten eben weg, siehe diejenigen, die auf Millionen-CryptoDollar „sitzen“ aber nie wieder rankommen 🙂
    Jede Möglichkeit, das Passwort samt Daten zu resetten, ist eine Form von Angriffsvektor, da trifft man dann eben Abwägungen und eine Balance.

    So, genug doziert. Vielen lieben Dank auch für diese Folge und einen schönen Abend euch!

    Antworten
  3. F. Netzer

    Hi all,
    könntet Ihr bitte das Sort-Tool in die Hausmeisterei mit aufnehmen? Danke.
    Irgendwie sagt er mir immer ich hätte dies schon gepostet, allerdings ist dies mein ERSTES mal!?!?!?

    Antworten
    1. stefan (0x0d.de)

      Ja, du hast deinen Kommentar quasi zweimal eingetragen.
      Der Grund ist der bei uns implementierte Freigabeprozess.
      Dieser ist zum einen zu unserem rechtlichen Schutz da,
      aber auch um Spam raus zu halten.
      Dadurch werden Kommentare, die man abschickt nicht direkt angezeigt, sondern erst nach der Freigabe durch uns.
      In deinem besonderen Fall, haben wir 2 Anfragen zur Freigabe in Abstand von 3 Minuten.
      Wie man sieht, haben wir beide zugelassen. =)

      Danke für den Hinweis, das ich was in den Shownotes vergessen habe.

      Lieben Gruß

      Stefan

      Antworten

Schreibe einen Kommentar zu Christoph Siemer Antworten abbrechen

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