---
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[^1]
   - *"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[^2] Accounts aller User zugreifen, sofern die Passwörter wiederverwendet wurden. (Folie: Link zu [https://haveibeenpwned.com/](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 ...

[^1]: Some effort required
[^2]: ...nicht durch MFA geschützten...

### 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

![XKCD 936](https://imgs.xkcd.com/comics/password_strength.png)

- 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

*Falls die Zeit es zulässt*

- Mittels PBKDF2 (oder ähnlich): Master-Passwort wird zu einem Schlüssel um die restlichen Passwörter verschlüsseln zu können
- Beispiel Bitwarden (weil doku gut erklärt & eigeninteresse): https://bitwarden.com/help/bitwarden-security-white-paper/#authentication-and-decryption

Für Folien
![](https://bitwarden.com/assets/lrLsAOcvBsN1vaYAaZQKt/a73a6f46d55cf705423aa7a6a12b7f8a/whitepaper-login.png)