Warum Angriffe kennen?

Stellt euch vor: Ihr habt AES-256 korrekt konfiguriert, ein starkes Passwort gewählt und TLS aktiviert. Trotzdem wird euer System kompromittiert. Wie? Weil der Angreifer gar nicht den Algorithmus gebrochen hat – er hat das Passwort aus einem Datenleck recycelt, den Handshake auf TLS 1.0 downgegradet, oder einfach in der Mitte gesessen und mitgelesen.

Wer Verschlüsselung einsetzen soll, muss verstehen, womit Angreifer versuchen, sie zu umgehen oder zu brechen. Die meisten erfolgreichen Angriffe richten sich nicht gegen den Algorithmus selbst, sondern gegen seine Implementierung, Konfiguration oder den Schlüsselaustausch.

Nach diesem Block könnt ihr:

• die wichtigsten Angriffe auf Verschlüsselung benennen und erklären (MITM, Replay, Brute-Force, Rainbow Tables)
• zu jedem Angriff die passende Gegenmaßnahme zuordnen
• erklären, warum Passwörter mit Salt und langsamen Hash-Algorithmen gespeichert werden müssen
• Padding Oracle, Downgrade und Side-Channel-Angriffe einordnen
• in einer Prüfungssituation Angriffsszenarien analysieren und Gegenmaßnahmen vorschlagen

Man-in-the-Middle (MITM)

Was passiert: Ein Angreifer schaltet sich unbemerkt zwischen zwei Kommunikationspartner. Er empfängt die Daten, liest oder manipuliert sie, und leitet sie weiter – beide Seiten glauben, direkt miteinander zu kommunizieren.

Alice                    Angreifer (Eve)                  Bob
  │                            │                            │
  │──── "Hallo Bob" ──────────►│                            │
  │                            │──── "Hallo Bob" ──────────►│
  │                            │◄─── "Hallo Alice" ─────────│
  │◄─── "Hallo Alice" ─────────│                            │
  │                            │                            │ 
  │                            │                            │ 
  │             Eve liest und kann Inhalte verändern        │

Voraussetzung: Der Angreifer muss sich im Netzwerkpfad befinden – z.B. im selben WLAN (ARP-Spoofing), als kompromittierter Router, oder durch DNS-Manipulation.

Gegenmaßnahmen:

• TLS mit Zertifikatsvalidierung: Der Browser prüft, ob das Zertifikat des Servers von einer vertrauenswürdigen CA (Certificate Authority – eine geprüfte Instanz, die Zertifikate ausstellt, details in Block 06) signiert wurde. Ein MITM kann kein gültiges Zertifikat für bank.de vorlegen – es sei denn, er hat Zugang zu einer CA.
• Certificate Pinning: Anwendungen hinterlegen den erwarteten Zertifikats-Fingerprint fest im Code („Pin”). Bei jeder Verbindung wird geprüft, ob das vorgelegte Zertifikat mit dem Pin übereinstimmt – selbst ein korrekt von einer CA ausgestelltes Zertifikat wird abgelehnt, wenn es nicht zum Pin passt. Schützt vor kompromittierten CAs.
• HSTS (HTTP Strict Transport Security): Browser speichern, dass eine Domain nur per HTTPS erreichbar ist. Ein MITM kann keine HTTP-Verbindung erzwingen (details in Block 08).

Merke: HTTPS schützt vor MITM – aber nur, wenn die Zertifikatsvalidierung korrekt durchgeführt wird. Apps oder Systeme, die Zertifikatsfehler ignorieren (curl -k, InsecureSkipVerify), heben diesen Schutz auf.

Replay-Angriff

Was passiert: Ein Angreifer zeichnet eine legitime, verschlüsselte Kommunikation auf und sendet sie zu einem späteren Zeitpunkt erneut – ohne sie entschlüsseln zu müssen.

Alice                    Angreifer (Eve)                  Server
  │                            │                            │
  │──── Login-Request ────────►│                            │
  │    (verschlüsselt)         │──── Login-Request ────────►│
  │                            │    (unverändert, später)   │
  │                            │◄─── Zugang gewährt ────────│
  │                            │                            │
  │                            │                            │
  │          Eve hat sich als Alice authentifiziert         │

Gegenmaßnahmen:

• Nonces (Number used once): Der Server schickt bei jeder Authentifizierung eine zufällige Zahl, die der Client in seine Antwort einbettet. Eine aufgezeichnete Antwort hat eine veraltete Nonce und wird abgelehnt.
• Timestamps: Nachrichten enthalten einen Zeitstempel. Anfragen, die älter als z.B. 5 Minuten sind, werden verworfen.
• Session-Tokens: Einmalige Token, die nach Verwendung ungültig werden.
• TLS schützt indirekt, da Sequenznummern in TLS-Records Replay verhindern.

Brute-Force-Angriff

Was passiert: Der Angreifer probiert systematisch alle möglichen Schlüssel oder Passwörter durch, bis er die richtige Kombination findet.

Angreifer testet:
  "aaaaaa" → falsch
  "aaaaab" → falsch
  ...
  "geheim" → TREFFER

Wie lange dauert das?

Gegenmaßnahmen:

• Lange, komplexe Passwörter (Passphrasen)
• Account-Lockout nach n fehlgeschlagenen Versuchen
• Rate Limiting und CAPTCHA
• Langsame Hash-Algorithmen für Passwörter (bcrypt, Argon2) – mehr dazu gleich
• Für Schlüssel: ausreichende Schlüssellänge (AES-128 ist praktisch unknackbar per Brute-Force)

Dictionary-Angriff: Statt allen Kombinationen werden bekannte Wörter, Passwortlisten (z.B. rockyou.txt mit 14 Millionen echten Passwörtern) oder Variationen davon probiert. Viel effizienter als reines Brute-Force.

Rainbow Tables und Salting

(Salt wurde in Block 01 eingeführt. Hier geht es darum, warum Salt speziell gegen Rainbow Tables wirksam ist.)

Das Problem ohne Salt:

Wenn Passwörter als einfache Hashes gespeichert werden, kann ein Angreifer mit einer Rainbow Table – einer vorberechneten Tabelle von Hashes für Millionen bekannter Passwörter – die Hashes in Sekundenschnelle nachschlagen.

Rainbow Table (vorberechnet):
  SHA-256("password")  → 5e884898da...
  SHA-256("123456")    → 8d969eef6e...
  SHA-256("hallo")     → 26b7fd8b55...
  ...

Angreifer findet Hash "5e884898da..." in der Datenbank
  → Nachschlagen → Klartext: "password"
  → Dauer: Millisekunden

Die Lösung: Salt

Ein Salt ist ein zufälliger Wert, der vor dem Hashing an das Passwort angehängt wird. Er wird zusammen mit dem Hash gespeichert.

Ohne Salt:
  Hash = SHA-256("password") → immer derselbe Hash

Mit Salt:
  Salt = "x7k2m9q1" (zufällig, für jeden User anders)
  Hash = SHA-256("password" + "x7k2m9q1") → völlig anderer Hash
  Gespeichert: Hash + Salt (kein Geheimnis, muss nicht versteckt werden)

  → Selbst gleiche Passwörter haben verschiedene Hashes
  → Rainbow Tables werden wertlos

Warum bcrypt / Argon2 statt SHA-256 für Passwörter:

SHA-256 ist absichtlich schnell designed (für Datei-Integrität). Schnell ist bei Passwörtern schlecht: Ein Angreifer kann Milliarden Hashes pro Sekunde berechnen.

bcrypt und Argon2 sind absichtlich langsam – sie haben einen konfigurierbaren Cost-Faktor:

bcrypt mit Cost-Faktor 12:
  → ~250ms pro Hash-Berechnung auf moderner Hardware
  → Angreifer schafft nur ~4 Versuche/Sekunde statt Milliarden
  → Salt ist in bcrypt eingebaut (wird automatisch generiert)

*SHA-256 kann mit Salt verwendet werden, ist aber immer noch zu schnell für Passwörter.

Merke: Passwörter werden nicht verschlüsselt, sondern gehasht – mit Salt und einem langsamen Algorithmus. Wenn jemand sagt „wir verschlüsseln die Passwörter” – hinterfragt das. Und wenn ihr SHA-256 ohne Salt für Passwörter seht: das ist ein schwerwiegender Sicherheitsfehler, den ihr benennen und beheben müsst.

Typischer Denkfehler

„AES-256 ist unknackbar, also bin ich sicher.” – Der Algorithmus mag sicher sein, aber die meisten Angriffe zielen nicht auf den Algorithmus. Ein schwaches Passwort, ein fehlender Salt, eine veraltete TLS-Version oder ein ignorierter Zertifikatsfehler – das sind die echten Einfallstore. Die Kette ist nur so stark wie ihr schwächstes Glied, und das ist fast nie AES.

Weitere relevante Angriffstypen

Die bisher behandelten Angriffe sind die häufigsten in der Praxis. Darüber hinaus gibt es spezialisierte Angriffe, denen ihr in bestimmten Kontexten begegnen werdet – besonders wenn ihr TLS-Konfigurationen prüft oder Legacy-Systeme absichert.

Padding Oracle Attack: Betrifft Blockchiffren im CBC-Modus ohne Authentifizierung. Der Angreifer kann durch Auswerten von Fehlermeldungen den Klartext Stück für Stück ermitteln. Gegenmaßnahme: AEAD-Modi wie GCM verwenden (kombiniert Verschlüsselung und Authentifizierung).

Downgrade-Angriff: Der Angreifer manipuliert den TLS-Handshake, damit Client und Server eine ältere, unsichere Protokollversion oder schwache Cipher Suite verwenden (z.B. TLS 1.0 statt TLS 1.3). Gegenmaßnahme: Alte TLS-Versionen serverseitig deaktivieren.

Side-Channel-Angriff: Angriff nicht auf den Algorithmus selbst, sondern auf seine Implementierung. Messungen von Stromverbrauch, Zeitverhalten oder elektromagnetischer Strahlung können Schlüsselinformationen verraten. Relevant vor allem für Hardware (Smart Cards, HSMs).

Übersicht: Angriff und Gegenmittel

Zusammenfassung

• Die meisten Angriffe richten sich nicht gegen Algorithmen, sondern gegen Implementierung, Konfiguration und menschliche Fehler
• MITM wird durch TLS + Zertifikatsvalidierung verhindert; Replay durch Nonces und Timestamps
• Brute-Force wird durch lange Passwörter und Account-Lockout erschwert; Rainbow Tables durch Salt + langsame Hashes (bcrypt/Argon2)
• Downgrade-Angriffe werden verhindert, indem alte TLS-Versionen serverseitig deaktiviert werden
• Für Passwörter gilt: Hashen, nicht verschlüsseln – mit Salt und langsamem Algorithmus

Selbsttest

1. Ein Angreifer zeichnet einen verschlüsselten Login-Request auf und sendet ihn eine Stunde später erneut. Um welchen Angriff handelt es sich, und welche Gegenmaßnahme hilft?
2. Warum ist SHA-256 ohne Salt für Passwörter unsicher, obwohl SHA-256 als sicherer Hash-Algorithmus gilt?
3. Erklärt den Unterschied zwischen einem Brute-Force-Angriff und einem Dictionary-Angriff.

Wie geht es weiter?

Ihr kennt jetzt die Angriffe und ihre Gegenmaßnahmen. Aber wie sieht asymmetrische Authentifizierung im täglichen Admin-Alltag aus? Block 10 zeigt SSH-Schlüsselauthentifizierung: das Werkzeug, mit dem ihr als Fachinformatiker*innen täglich auf Server zugreift.