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

1. Michael Schmitz 26. Februar 2023 um 11:20 Uhr

   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 2. März 2023 um 0:47 Uhr

   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 12. April 2023 um 14:51 Uhr

   Hi,
   gute und interessante Sendung. Könntet Ihr bitte das Sort-Tool in die Hausmeisterei mit aufnehmen? Danke.

   Antworten ↓
   1. stefan (0x0d.de) 12. April 2023 um 18:29 Uhr

      fdupes:
      https://github.com/adrianlopezroche/fdupes
      Ja, du hast recht, das ist mir durchgegangen.
      Ich gelobe Besserung.

      Antworten ↓
4. F. Netzer 12. April 2023 um 14:54 Uhr

   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) 12. April 2023 um 18:35 Uhr

      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 ↓