Web Security rund um die Anmeldung

Es gibt verschiedene Anmeldemechanismen!

Verschiedene Möglichkeiten der Anmeldung sind mit Browser-Bordmitteln realisierbar:

• Formular
• (http auth)
• SSL-Clientzertifikat

...und natürlich noch diverse Single-Sign-On-Lösungen (z.B. OpenID, BrowserID, Facebook/Google login) mit „Dritt-Server-Unterstützung“

Der Klassiker: Login-Formular

Übertragen der Formulardaten via https

Wichtig: Formular bereits auf einer https-Seite

• Form-POST von https nach http: Browser-Warnung
• Sonst keine Gewißheit für Benutzer, dass Daten sicher übertragen werden

SSL Stripping

Aktiver Angreifer („Man in the middle“): Kann Daten lesen und manipulieren, aber keine validen SSL-Zertifikate erzeugen

<form action="https://my.site/login" method="post">

<form action="http://my.site/login" method="post">

<Virtualhost *:80>
  ServerName my.site
  Redirect permanent / https://my.site/
</VirtualHost>

Http Strict Transport Security (HSTS) als Hilfe gegen SSL Stripping

Bruteforce

Was tun gegen systematisches Ausprobieren?

Passwort-Vorgaben

Mindestlänge, Mindestkomplexität haben gewissen Wert

„Gängelung“ durch zu häufiges Wechseln: Kein Sicherheitsgewinn

Passwort-Knacker auf gängige Schemata vorbereitet

Hinweise für gute Passwortwahl geben!

Tipps für gute Passwörter

Lieber längere Passwörter als Sonderzeichen verwenden

Passwörter nicht mehrfach verwenden, Hinweis auf Generatoren mit Masterpasswort wie z.B. Password Hasher

Brauchbare Schemata für Merkhilfen:

• „correct horse battery staple“-Methode
• Anfangsbuchstaben der Wörter eines Nonesense-Satzes:
  „Meine Tante Martha verputzt zum Frühstück 7 Rollmöpse mit Senf, aber keinen Kaffee“ ⇒ MTMvzF7RmS,akK

Shouldersurfing

Das Passwort als einzige Hürde?

Google Authenticator! (bzw. einen seiner Forks)

Standard: RFC6238 (Time-based OTP)

Apps für Android, iOS, Blackberry

SSL Clientzertifikate

Funktion: Symmetrisch zum SSL-Serverzertifikat

Authentisierung, wenn

• Zertifikat von konfigurierter CA signiert
• Nicht abgelaufen
• Nicht in Revocation List

„Ersatzpasswort“ für Apps

Häufig gewünscht: API-Zugang, Mashups, etc.

User-Passwort in fremde Apps eingeben: Schlecht

• Liegt dort im Klartext
• Passwort ändern wird aufwendig

Tokens vs. Passwort-Wechsel

Vorsicht: User-Passwort-Wechsel macht OAuth-Tokens nicht ungültig

Best Practice:

• Liste mit vergebenen Tokens (samt Rechten)
• Möglichkeit, einzelne Tokens zurückzuziehen
• Hinweis bei erfolgreicher Passwort-Änderung, dass verknüpfte Apps nach wie vor Zugriff haben

Des Nutzers Kronjuwelen...

Bisherige Betrachtung:

• Das System ist sicher
• Der Benutzer verwendet überall unterschiedliche Passwörter

Bisher: Passwort-Sicherheit im Kontext Web-Login

• Bandbreite limitiert Anzahl Versuche/Sek
• Möglichkeit der Einflußnahme (Captcha, ...)

Passwörter speichern

Worst-Case-Vorbereitung: Angreifer hat Zugriff aufs System. Nutzer schützen!

Passwörter nie im Klartext!

Passwörter nie reversibel verschlüsselt!

Lösung: Hashes („Fingerabdruck“ des Passworts)

Hashfunktionen

Kryptographischer Hash („Falltür-Funktion“)

• Einfach zu bestimmen
• Rückrichtung (passende Eingabe, die zu Hashwert X führt): Schwierig

Unschön: Identische Passwörter sind so erkennbar

Einfache Berechnung: Schnelles Durchprobieren möglich

• Rainbow Tables
• Implementierung für GPUs
• Google: bfb0f76744e188dda17bb62a22920c95

  

Hashes und Salt

Salt-Wert: Zeichenfolge, die dem Passwort hinzugefügt wird:

Statt Hash(pass): Hash(salt + pass)

Salt-Wert mitspeichern

• Identisches Passwort erzeugt nun unterschiedliche Hashes
• Vorberechnen (Rainbow Tables) schwieriger

Salt-Wert muss nicht zwingend zufällig sein; idealerweise jeden Salt-Wert nur 1x verwenden

Pepper und Garlic

Pepper: Weiterer, seiteneinheitlicher „Salt-Wert“

Nicht in Datenbank gespeichert

Nutzen umstritten. Wenn verwenden, dann HMAC-Funktion benutzen

Garlic: „New kid on the block“

Parameter, um Speicherbedarf der Hashfunktion zu erhöhen

Abwehr gegen GPU-Berechnungen

Weiteres Ausbremsen des Angreifers

Langsame Hashfunktionen verwenden

Also scrypt/bcrypt, nicht SHA256, SHA512, ... direkt

Mithalten mit Wettrüsten: Nötige Rechenzeit erhöhen

Wenn Algorithmus das nicht hergibt: Bits im gespeicherten Hash wegwerfen (und beim Login ignorieren)

Klassisches Session-Management

Wiedererkennen eines Users über Requests hinweg

Generieren einer Session-ID

Session-ID wird bei jedem Request mitgeliefert (typischerweise Cookie)

Serverseitig: Speicher, der mit Session-ID assoziiert ist, enthält eigentliche Session-Informationen

Session-ID prediction

Erzeugen der Session-ID: Containerabhängig

Wenn Session-ID vorhersagbar: „Einstieg“ in fremde Sessions möglich

Session Fixation Attack

Ziel: Opfer eine dem Angreifer bekannte Session „unterschieben“

Voraussetzung: Session-ID ist von außen setzbar - z.B. Tomcats Fallback bei fehlenden Cookies:
http://my.site/some/url;jsessionid=...

Sichern der Session-ID

Session-ID vor Angriffen schützen

<session-config>
  <cookie-config>
    <http-only>true</http-only>
  </cookie-config>
</session-config>

<session-config>
  <cookie-config>
    <secure>true</secure>
  </cookie-config>
</session-config>

Mehrfach-Logins

Sollen mehrere gleichzeitig gültige Session-Cookies möglich sein?

Vorteil: Auf mehreren Browsern angemeldet bleiben

Nachteil: Diebstahls-Risiko, vergessen abzumelden, etc.

Vergessene Passwörter

Fragen nach Lieblingstier, Name der Mutter, etc. leicht zu erraten

Recovery per E-Mail

• Nie Klartext-Passwörter per Mail
• Einmal-Links mit begrenzter Lebenszeit, ggfs. auf IP-Adresse beschränkt
• Problem: E-Mail als Single Point of Failure

Vergessene Passwörter und Two-Factor-Authentication

Authentisierungs-Token verloren?

Einloggen mittels „Notfall-Keys“, Re-Keying

→ Kein Single Point of Failure!