Benedikt Galbavy abb89dbc6e Finished implementation

2025-10-05 14:45:32 +02:00

3.5 KiB

Raw Blame History

author
Benedikt Galbavy

Präsentation "Secure Password Management"

Draft: Struktur

Note: Die angeführte Struktur ist die Langfassung von Punkten, die ich in irgendeiner Form erwähnen wollen würde - die Präsentation selbst hat aber natürlich weit weniger Fließtext auf den Folien

Intro

Ziel: Ein User soll glaubhaft machen können, dass er der Besitzer eines Accounts ist
- "Proof-by-ownership": OTP/TOTP (Präs B5 erwähnen), Hardware-Keys (U2F Standard), Biometrics (bissl hergeholt)
- "Proof-by-knowledge": Security Questions, Passwörter
Problematik: Ich muss das Passwort speichern, um es abgleichen zu können - und wenn meine Application darauf zugreifen kann, kann es auch ein Angreifer¹
- "Warum so schlimm? Eine komprimierte Datenbank ist doch eh schon ein worst-case Szenario …" Weil Menschen dumm sind und ihre Passwörter wiederverwenden → ein Angreifer kann sich plötzlich in alle² Accounts aller User zugreifen, sofern die Passwörter wiederverwendet wurden. (Folie: Link zu https://haveibeenpwned.com/).
- Paar Punkte zu
- Ansatz 1: Passwort DB verschlüsseln → Problem: Schlüssel muss auch gespeichert sein → Loop zu Problem
- Ansatz 2: Wenn es doch nur eine Einbahnfunktion gebe ...

Hashing

Eine Hashfunktion gibt bei selben Input auch wieder einen identen Output → anstelle von pw mit pw zu vergleichen, kann hash mit hash verglichen werden, aber aus hash kann nicht das passwort geschlossen werden (Hier die Hashfunktion mit einem hübschen Pfeil auf der Tafel verdeutlichen)
Algorithmen Beispiele aufzählen
Wenn ein input immer zum selben output führt, kann für jedes passwort der hash precomputed werden -> Rainbow Tables Demo

Entropy

Rainbow tables können praktisch nur beschränkt Daten speichern -> kein standard passwort verwenden

nis2 empfehlungen
Entropy = Mögliche Passwörter aufgrund von Kriterien:
- Länge
- Character-Set (Buchstaben (klein/groß), Zahlen, (welche) Sonderzeichen?)
- Wörter & Namen? → Wenn ja, Tauschregeln von Buchstaben (0 ↔ O, 1 ↔ l ↔ I ↔ !)

Salt

"Gratis" Entropy, am Server angehängt
Salt: Unique pro Nutzer
Pepper: Global für Application

Algorithmen spezifisch für Passwörter

Tunable CPU & Memory usage um Brute-Force zu erschweren
Beispiele (Pbkdf, bcrypt, scrypt, ...)

PBKDF2

key = pbkdf2(password, salt, iterations-count, hash-function, derived-key-len)
(Überleitung zu Demo)

Demo

https://gitea.nanopenguin.at/nanopenguin/itse-presentation (WIP)

TODOs:

Mehr Password-Encoders, ggf. eigens geschrieben
DB Anbindung (zur besseren Veranschaulichung)

Bonus 1: Encoding Migration

Falls die Zeit es zulässt

Anhand der Code Demo, {enc}-Prefix
Challenges: Da das Passwort nicht bekannt ist, muss sich der Nutzer erneut einloggen um das Passwort recodieren zu können

Bonus 2: Password Managers