Webtechnologien
Wintersemester 2024
<!DOCTYPE HTML> <html lang="de"> <head> <meta charset="utf-8"> <title>Umgang mit Zugangsdaten</title> <meta name="viewport" content="width=792, user-scalable=no"> <base target="_blank"> <link rel="stylesheet" href="/assets/styles/presentation.css"> </head> <body class="list"> <div class="notes"> <a href="text.html" target="_parent">♯</a> <a href="/notes/" target="_blank">♫</a> </div> <header class="caption"> <h1>Umgang mit Zugangsdaten</h1> </header> <section id="umgang-mit-zugangsdaten" class="slide cover"><div><h2>Umgang mit Zugangsdaten</h2> </div></section> <section class="slide" id="begriffsunterscheidung"><div><h2>Begriffsunterscheidung</h2> <ul> <li><strong>Authentisierung</strong> bezeichnet das Nachweisen einer Identität,</li> <li><strong>Authentifizierung</strong> ist die Bestätigung dieser Behauptung und</li> <li><strong>Autorisierung</strong> das daraus folgende Einräumen bestimmter Rechte.</li> </ul> <footer> <p>Irgendwann steht jeder mal vor der Aufgabe, Login-Funktionalität o.ä. zu implementieren. Ziel dieser Seite ist deshalb, einen Überblick und Startpunkt zu diesem Thema zu bieten. Schauen wir uns zuerst die Begrifflichkeiten an.</p> <ol> <li>Die Authentifizierung ist der Nachweis, dass jemand tatsächlich die Person ist, die er vorgibt zu sein. Dies geschieht zum Beispiel durch: <ul> <li>Eingabe von Benutzername und Passwort</li> <li>Zwei-Faktor-Authentifizierung (2FA)</li> <li>Biometrische Daten (Fingerabdruck, Gesichtserkennung)</li> </ul> </li> <li>Die Authentisierung ist die Überprüfung der Echtheit oder Authentizität von etwas, zum Beispiel: <ul> <li>Die Prüfung, ob Benutzername und Passwort stimmen</li> <li>Die Validierung eines digitalen Zertifikats</li> <li>Die Verifikation einer digitalen Signatur</li> </ul> </li> </ol> <ul> <li>Beispiel: Wenn Sie sich bei einer Webanwendung anmelden, durchlaufen Sie zuerst die Authentifizierung (Sie weisen nach, dass Sie der rechtmäßige Benutzer sind). Die Anwendung führt dann eine Authentisierung durch, indem sie prüft, ob Ihre Anmeldedaten echt und gültig sind.</li> </ul> </footer> </div></section> <section class="slide" id="authentisierung"><div><h2>Authentisierung</h2> <p>Authentisierung ist auf <a href="https://de.wikipedia.org/wiki/Authentifizierung">drei Wegen möglich</a>:</p> <table> <thead> <tr> <th scope="col">Nachweis</th> <th scope="col">Verb</th> <th scope="col">Beispiel</th> </tr> </thead> <tbody> <tr> <td>Kenntnis einer Information</td> <td>weiß etwas</td> <td>Passwort</td> </tr> <tr> <td>Verwendung eines Besitztums</td> <td>hat etwas</td> <td>Schlüssel</td> </tr> <tr> <td>Gegenwart der Person selbst</td> <td>ist etwas</td> <td>biometrisches Merkmal</td> </tr> </tbody> </table> <footer> <ol> <li>Wissen</li> <li>Schlüssel / Karte / Ausweis</li> <li>Retina-Scan / Fingerabdruck / Venen der Hand</li> </ol> </footer> </div></section> <section class="slide shout" id="umgang-mit-passwörtern"><div><h2>Umgang mit Passwörtern</h2> </div></section> <section class="slide" id="hashing-und-brute-force"><div><h2>Hashing und Brute Force</h2> <ul> <li>Passwörter sollten niemals in Klartext gespeichert werden</li> <li>Stattdessen immer mit einer <a href="https://de.wikipedia.org/wiki/Kryptologische_Hashfunktion">kryptologische Hashfunktionen</a> umwandeln</li> <li>Verbreitete Algorithmen wie MD5 oder SHA1 sind schnell, für diesen Anwendungsfall aber genau deswegen ungeeignet, da anfällig für <a href="https://de.wikipedia.org/wiki/Brute-Force-Attacke">Brute-Force-Angriffe</a></li> <li>Aufwändiges Hashen: <a href="https://de.wikipedia.org/wiki/Argon2">Argon2</a> 🥇, <a href="https://de.wikipedia.org/wiki/PBKDF2">PBKDF2</a>, <a href="https://de.wikipedia.org/wiki/Bcrypt">bcrypt</a></li> <li>Langsamkeit für 1 Berechnung irrelevant, Brute-Force-Angriffe werden aber enorm erschwert</li> </ul> <footer> <ul> <li>Eine der grundlegenden Regeln im Umgang mit Zugangsdaten ist, Passwörter niemals als Klartext zu speichern. Aus dem simplen Grund, dass sie gestohlen werden könnten.</li> <li>Hashfunktionen: lassen sich nicht zurückrechnen</li> <li>Aufwändiges Hashen: Algorithmen zum Speichern von Passwörtern, die absichtlich langsam sind</li> <li>Ihre Langsamkeit fällt in Relation zu anderen Faktoren (Data Sanitization, Datenbankabfragen, Paketumlaufzeit) nicht ins Gewicht – vor allem, da im Normalfall nur eine Berechnung durchgeführt wird.</li> <li>Brute-Force-Angriffe hingegen werden enorm erschwert – auch, da z.B. bcrypt einen einstellbaren Kostenfaktor hat, der sich auch nachträglich noch erhöhen lässt.</li> </ul> </footer> </div></section> <section class="slide" id="rainbow-tables"><div><h2>Rainbow Tables</h2> <ul> <li>Beim Knacken von Passwort-Hashes ist <a href="https://de.wikipedia.org/wiki/Time-Memory_Tradeoff">Zeit wertvoller als Speicher</a></li> <li>daher existieren für Algorithmen wie MD5 vorgefertigte Listen populärer Passwörter und Wörterbucheinträge, <a href="https://de.wikipedia.org/wiki/Rainbow_Table">Rainbow Tables</a></li> <li>leicht über z.B. Google zugänglich: <a href="https://www.google.de/search?q=a2b0ef405bae8278b51270241c4084c5">google.de/search?q=a2b0ef405bae8278b51270241c4084c5</a></li> </ul> </div></section> <section class="slide" id="gegenmaßnahmen-gegen-rainbow-tables"><div><h2>Gegenmaßnahmen gegen Rainbow Tables</h2> <ul> <li>Salting: Hinzufügen zufälliger Zeichenkette zum Passwort</li> <li>wird mit dem Passwort in der Datenbank gespeichert</li> <li>Pepper: Wie Salt, aber wird im Code der Anwendung gespeichert (daher immer gleich, aber losgelöst von der Datenbank)</li> <li>beides schützt vor <a href="https://de.wikipedia.org/wiki/W%C3%B6rterbuch-Angriff">Wörterbuch-Angriffen</a> / Rainbow Tables</li> </ul> <p><img src="Salting.svg" alt="Salting" class="full-width" /></p> </div></section> <section class="slide" id="verzögerung"><div><h2>Verzögerung</h2> <ul> <li>Abwehr von <a href="https://de.wikipedia.org/wiki/Brute-Force-Attacke">Brute-Force-Angriffen</a> über die Anwendung</li> <li>z.B. nach x Login-Versuchen künstliche Verzögerung per <a href="https://en.wikipedia.org/wiki/Exponential_backoff">Exponential-Backoff</a>-Algorithmus</li> </ul> <footer> <ul> <li>Nur möglich, wenn Angreifer keinen Zugriff auf die Datenbank haben, sondern von Außen angreifen</li> </ul> </footer> </div></section> <section class="slide" id="umgang-mit-cookies"><div><h2>Umgang mit Cookies</h2> <ul> <li>Web-Anwendungen speichern Zugangstoken meist in <a href="https://en.wikipedia.org/wiki/Magic_cookie">Cookies</a></li> <li>HTTP ist zustandslos → Cookies werden mit jeder Anfrage mitgeschickt</li> <li>Diebstahl des Cookies ermöglicht Zugriff auf Anwendung als bestohlener Nutzer</li> <li>darum Cookies immer mit den Flags <a href="https://www.owasp.org/index.php/SecureFlag"><code class="language-plaintext highlighter-rouge">secure</code></a> und <a href="https://www.owasp.org/index.php/HttpOnly"><code class="language-plaintext highlighter-rouge">HttpOnly</code></a> setzen</li> <li>dadurch Übertragung nur über HTTPS und nicht über JS lesbar</li> </ul> </div></section> <section class="slide" id="weitere-punkte"><div><h2>Weitere Punkte</h2> <p><a href="https://xkcd.com/936/"><img src="password_strength.png" alt="XKCD 936 – Password Strength" class="right" width="333" /></a></p> <ul> <li>Logins sollten immer über HTTPS laufen, sonst alles andere egal</li> <li>Passwort-Regeln: Hauptsache lang</li> <li>E-Mail-Adresse statt Benutzernamen – die sind immer frei, gut zu erinnern und gut zu validieren.</li> <li>Logging ist gut, aber keine Passwörter</li> <li>Bieten Sie eine Logout-Option an, die alle Sessions explizit zerstört und auch den Session-Cookie löscht</li> </ul> <footer> <ul> <li>E-Mail-Adresse statt Benutzernamen – die sind immer frei, gut zu erinnern und gut zu validieren.</li> </ul> </footer> </div></section> <section class="slide" id="links"><div><h2>Links</h2> <ul> <li>Googles <a href="https://code.google.com/p/browsersec/wiki/Main">Browser Security Handbook</a></li> <li>OWASP: <a href="https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet">PHP Security Cheat Sheet</a>, <a href="https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet">Forgot Password Cheat Sheet</a> und alles andere unter <a href="https://www.owasp.org/index.php/Main_Page">owasp.org</a></li> <li>CrackStation: <a href="https://crackstation.net/hashing-security.htm">Salted Password Hashing - Doing it Right</a></li> <li>Jacob Hoffman-Andrews – <a href="https://jacob.hoffman-andrews.com/README/why-you-need-a-www/">Why you need a ‘www.’</a></li> <li>Mike Hearn – <a href="https://blog.plan99.net/building-account-systems-f790bf5fdbe0">Building account systems</a></li> </ul> </div></section> <div class="progress"><div></div></div> <script src="/assets/scripts/shower.js"></script> <script src="/assets/scripts/shower-notes.js"></script> <script src="/assets/scripts/editor.js"></script> <script> document.querySelectorAll('[bg]').forEach(el => el.style.backgroundImage = `url(${el.attributes.bg.value})`); </script> </body> </html>