Sechs Risiken, die man sehen muss, um sie zu verstehen

Wie schnell fällt ein Passwort?

Angreifer raten nicht „von Hand" — sie probieren Milliarden Kombinationen pro Sekunde. Tipp ein Passwort ein (gern erfunden) und zeig der Gruppe live, was Länge und Zeichenvielfalt bewirken.

Schätzung über Brute-Force (alle Kombinationen). Steht das Passwort in einer Wortliste oder einem Leak, fällt es in Sekunden — egal wie „komplex" es aussieht. „Sommer2024!" erfüllt jede Komplexitätsregel und ist trotzdem leicht erratbar.

Live-Angriff über den Vortrag

Ein einfacher Brute-Force-Algorithmus läuft hier direkt im Browser und zählt, wie viele Kombinationen er durchprobiert. Er prüft dabei bewusst feste 12 Zeichen — er „kennt" die Länge also. Wirf ein Passwort aus dem Publikum ein und lass den Zähler die ganze Schulung über weiterlaufen — es geht nicht ums Knacken, sondern um die schiere Menge an Versuchen und darum, wie wenig davon selbst „viel" gegen den Schlüsselraum ausrichtet.

• Länge schlägt Komplexität. 4 zufällige Wörter sind stärker und merkbarer als „P@ssw0rt!".
• Passwort-Manager für zufällige, einzigartige Passwörter pro Dienst.
• MFA / 2FA überall — ein geknacktes Passwort reicht dann nicht mehr.
• Keine Wiederverwendung: ein Leak darf nicht alle Konten öffnen.

SQL-Injection: Login umgehen und Kundendaten abgreifen

Dieser nachgebaute Login setzt die Datenbank-Abfrage direkt aus der Eingabe zusammen — ein klassischer Fehler. Logg dich ohne Passwort ein und zeig der Gruppe, warum.

Beispiel 1 · Login umgehen

So sieht die Abfrage an der Datenbank aus:

Beispiel 2 · Kundendaten über die Bestellsuche

Ein Shop-Suchfeld hängt den Suchbegriff direkt in die Abfrage. Such nach einer Bestellnummer — oder setz den Angriff ein und sieh, wie plötzlich alle Kundendaten herausfallen.

So sieht die Abfrage an der Datenbank aus:

Warum das passiert

Mit der Eingabe ' OR '1'='1 wird die Bedingung immer wahr — die Datenbank gibt den ersten Benutzer (oft den Admin) zurück, ganz ohne Passwort. Der sichere Code nutzt parametrisierte Abfragen: Eingaben werden als Daten behandelt, niemals als Teil des Befehls.

• Prepared Statements / Parameter-Binding statt Strings zusammenbauen.
• Eingaben validieren und mit minimalen DB-Rechten arbeiten.
• Betrifft nicht nur Logins: Suchfelder, Filter, URLs, APIs — überall, wo Eingaben in Queries fließen.

Script-Injection (XSS): der Kommentar, der mitliest

Ein Kommentarbereich zeigt Beiträge ungeprüft an. Ein Angreifer hinterlässt einen Kommentar mit verstecktem Script — und liest ab da alles mit, was andere auf der Seite eintippen, sogar das Passwort. Schalte zwischen unsicher und sicher um und tipp unten ins Login. (Die Ausführung ist hier sicher nachgestellt.)

Schritt 1 · Angreifer schreibt einen Kommentar

Kommentare

Schritt 2 · Eine Kollegin öffnet die Seite und meldet sich an

Das Passwortfeld zeigt nur Punkte — der Angreifer bekommt trotzdem den Klartext.

Was der Angreifer in Echtzeit mitliest

• Ausgabe immer escapen (HTML-Encoding) — Kommentare als Text anzeigen, nie als Markup.
• Content-Security-Policy setzen, Framework-Schutz (Auto-Escaping) nicht abschalten.
• Ein gespeichertes Script trifft jeden Besucher: Tastatureingaben, Passwörter, Session-Cookies, Weiterleitungen.

Credentials per E-Mail — wo landet das alles?

Eine Mail mit Passwort oder API-Key fühlt sich „direkt" an. Tatsächlich hinterlässt sie überall Kopien, die praktisch nie wieder verschwinden. Zeig der Gruppe den Weg:

Mitnehmen für die Praxis (Spickzettel)

Phishing erkennen: die verdächtigen Stellen finden

Vier Mails, wie sie im Consulting-Alltag ankommen — Rechnung, Login-Warnung, Chef-Anweisung, IT-Support. Wähl ein Szenario und klick im Text auf alles, was dich stutzig macht. Die Seite deckt auf, welche Warnsignale du gefunden hast.

• Absender prüfen: angezeigter Name ≠ echte Adresse. Auf die Domain schauen, nicht auf den Namen.
• Links vor dem Klick prüfen: Maus drüberhalten, Ziel-Domain lesen — nie blind klicken.
• Druck & Dringlichkeit sind das häufigste Muster. Bei Geld/Zugängen: über einen zweiten, bekannten Kanal rückfragen (Anruf an bekannte Nummer, nicht die aus der Mail).
• Im Zweifel melden statt löschen — IT/Security kann warnen, bevor Kollegen klicken.

Live-Credentials in einer KI — und was Dritte daraus machen

KI-Tools helfen enorm — aber alles, was man hineinkopiert, verlässt den eigenen Rechner. Hier ein typischer „schnell debuggen"-Prompt. Schick ihn ab und sieh, was ein Scanner findet, wohin die Daten fließen und was im Ernstfall passiert. (Alle Werte sind erfunden, nichts wird gesendet.)

• Nie echte Secrets oder Mandantendaten in einen Prompt — Platzhalter/Dummy-Werte verwenden.
• Nur freigegebene Enterprise-/Team-KI mit Zero-Retention und ohne Training auf Eingaben; private Consumer-Konten tabu für Mandanten-Inhalte.
• Secrets gehören in einen Secret-Manager, nicht in Chats, Tickets oder Prompts.
• Einmal geleakt = verbrannt: exponierte Schlüssel/Passwörter sofort rotieren, nicht „beobachten".