Cryptography Fuer Hacker: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Kryptografie ist im offensiven Sicherheitskontext kein isoliertes Spezialthema, sondern Teil fast jeder realen Zielumgebung. Webanwendungen signieren Tokens, APIs verschluesseln Transportverbindungen, Betriebssysteme speichern Passwort-Hashes, VPNs handeln Schluessel aus, Cloud-Dienste nutzen Zertifikate, Datenbanken verschluesseln Felder oder ganze Volumes. Wer Systeme testet, muss deshalb nicht nur wissen, wie Algorithmen theoretisch funktionieren, sondern vor allem, wie sie in echten Architekturen eingesetzt, falsch konfiguriert oder unsauber implementiert werden.

Der wichtigste Perspektivwechsel lautet: In der Praxis wird selten AES oder RSA direkt "gebrochen". Erfolgreiche Angriffe entstehen fast immer an den Rändern der Kryptografie. Typische Schwachstellen sind schlechte Schluesselverwaltung, schwache Zufallszahlen, wiederverwendete Nonces, unsichere Betriebsmodi, fehlerhafte Zertifikatspruefung, veraltete Protokollversionen, fehlende Integritaetssicherung oder Logikfehler rund um Token, Sessions und Passwort-Reset-Prozesse. Genau dort arbeitet ein Pentester.

Ein sauberer Workflow beginnt nicht mit mathematischer Tiefe, sondern mit Systemverstaendnis. Zuerst wird geklaert, welche Daten geschuetzt werden sollen, wo Schluessel liegen, welche Vertrauensgrenzen existieren und welche Komponenten kryptografische Entscheidungen treffen. In Webprojekten betrifft das oft Session-Cookies, JWTs, CSRF-Tokens, Passwort-Reset-Links, API-Signaturen und TLS-Konfigurationen. Im Netzwerkbereich kommen Zertifikatsketten, VPN-Parameter, SSH-Konfigurationen und interne PKI-Strukturen hinzu. Grundlagen zu Transport, Protokollen und Kommunikationspfaden vertiefen Netzwerke Fuer Hacker und Tcp Ip Verstehen Fuer Hacking.

Im Pentest ist Kryptografie deshalb nie nur ein "Crypto-Check". Sie ist Teil der Gesamtmethodik. Eine schwache Passwort-Hashing-Konfiguration kann zu Account-Takeover fuehren. Ein falsch validiertes Zertifikat kann Man-in-the-Middle-Angriffe ermoeglichen. Ein signierter, aber nicht verschluesselter Token kann sensible Claims offenlegen. Ein verschluesselter, aber nicht authentifizierter Datenstrom kann manipuliert werden. Wer diese Zusammenhaenge erkennt, findet reale Angriffspfade statt akademischer Randfaelle.

Ebenso wichtig ist die Abgrenzung zwischen legitimer Analyse und blindem Tool-Einsatz. Tools zeigen Cipher Suites, Zertifikatsfehler oder Header an, aber sie erklaeren nicht automatisch das Risiko im Anwendungskontext. Ein Pentester muss bewerten, ob ein kryptografischer Befund nur formal unschoen oder praktisch ausnutzbar ist. Genau diese Einordnung trennt oberflaechliche Checks von belastbaren Sicherheitsbewertungen, wie sie auch in Pentesting Methodik und Web Security Grundlagen eine zentrale Rolle spielt.

Viele Sicherheitsprobleme beginnen damit, dass Entwickler oder Administratoren kryptografische Primitive verwechseln. Hashing, Verschluesselung, digitale Signaturen und Message Authentication Codes loesen unterschiedliche Probleme. Wer sie falsch kombiniert, erzeugt Systeme, die auf den ersten Blick sicher wirken, aber in der Praxis angreifbar sind.

Hashing dient der Einwegabbildung von Daten. Ein guter kryptografischer Hash ist deterministisch, schnell berechenbar und soll Kollisionen sowie Rueckrechnung praktisch unmoeglich machen. Fuer Passwortspeicherung reicht ein normaler Hash wie SHA-256 jedoch nicht aus, weil er zu schnell ist. Angreifer koennen Milliarden Kandidaten pruefen. Deshalb werden fuer Passwoerter adaptive Verfahren wie Argon2, bcrypt oder scrypt eingesetzt. Mehr dazu vertieft Hashing Verstehen und Password Cracking Grundlagen.

Verschluesselung ist dagegen reversibel. Symmetrische Verfahren wie AES nutzen denselben geheimen Schluessel fuer Ver- und Entschluesselung. Asymmetrische Verfahren wie RSA oder elliptische Kurven arbeiten mit Schluesselpaaren. In realen Protokollen werden beide Welten kombiniert: asymmetrisch fuer Authentisierung und Schluesselaustausch, symmetrisch fuer die eigentliche Datenuebertragung. Das ist effizienter und sicherer als reine Public-Key-Verschluesselung grosser Datenmengen.

Digitale Signaturen bestaetigen Authentizitaet und Integritaet. Sie beweisen, dass Daten von einem Besitzer des privaten Schluessels stammen und seit der Signatur nicht veraendert wurden. Ein haeufiger Denkfehler ist, Signatur mit Geheimhaltung gleichzusetzen. Signierte Daten koennen vollkommen lesbar sein. Umgekehrt kann etwas verschluesselt, aber ohne Integritaetsschutz manipulierbar sein.

MACs wie HMAC liefern Integritaet und Authentizitaet auf Basis eines gemeinsamen geheimen Schluessels. Sie sind keine Signaturen im asymmetrischen Sinn, aber fuer viele interne Systeme oder API-Signaturen genau das richtige Werkzeug. Fehler entstehen oft, wenn Entwickler selbst "Signaturen" bauen, etwa durch simples Konkatenieren von Parametern und Hashen ohne kanonische Sortierung, ohne Trennzeichen oder ohne Replay-Schutz.

• Hashing beantwortet die Frage, ob Daten gleich sind oder ob ein Geheimnis sicher abgeleitet gespeichert werden kann.
• Verschluesselung schuetzt Vertraulichkeit, aber nicht automatisch Integritaet.
• Signaturen und MACs schuetzen Integritaet und Authentizitaet, aber nicht automatisch Vertraulichkeit.

Im Pentest ist diese Trennung entscheidend. Wenn ein System etwa "verschluesselte" Cookies nutzt, muss geprueft werden, ob sie nur kodiert, wirklich verschluesselt oder zusaetzlich authentifiziert sind. Bei Tokens ist zu klaeren, ob Claims nur signiert oder auch vertraulich behandelt werden. Bei Passwortdatenbanken ist relevant, ob echte Passwort-Hashing-Verfahren mit Salt und passenden Kostenparametern eingesetzt werden oder nur schnelle Standard-Hashes. Genau diese Unterschiede entscheiden darueber, ob ein Befund kosmetisch oder kritisch ist.

Symmetrische Kryptografie ist das Arbeitspferd moderner Systeme. In fast jedem Protokoll, jeder Festplattenverschluesselung und vielen Anwendungsfunktionen steckt am Ende ein symmetrischer Algorithmus, meist AES oder ChaCha20. Der Algorithmus selbst ist selten das Problem. Kritisch sind Betriebsmodus, Schluesselableitung, Nonce-Management und Integritaetsschutz.

Ein klassischer Fehler ist die Nutzung von AES-CBC ohne zusaetzliche Authentifizierung. CBC kann Vertraulichkeit liefern, aber keine robuste Integritaet. Wenn Fehlermeldungen oder Timing-Unterschiede Informationen preisgeben, entstehen Padding-Oracles. Diese Angriffe sind kein theoretischer Sonderfall, sondern wurden in realen Anwendungen, Frameworks und proprietaeren Protokollen immer wieder ausgenutzt. Moderne Designs setzen deshalb auf AEAD-Verfahren wie AES-GCM oder ChaCha20-Poly1305, die Verschluesselung und Authentifizierung kombinieren.

Ebenso kritisch ist der Umgang mit IVs und Nonces. Ein IV in CBC muss unvorhersehbar sein, ein Nonce in GCM muss vor allem eindeutig sein. Wiederverwendung kann katastrophal sein. Bei GCM fuehrt Nonce-Reuse unter demselben Schluessel nicht nur zu Informationsverlust, sondern kann Integritaet kompromittieren. In proprietaeren Implementierungen sieht man oft feste IVs, aus Zeitstempeln abgeleitete Nonces oder Zaehler, die nach Neustarts wieder bei null beginnen. Solche Fehler sind fuer Angreifer deutlich wertvoller als jede Diskussion ueber Schluessellaengen.

Ein weiterer Schwachpunkt ist die Schluesselableitung. Wenn Anwendungen Benutzerpasswoerter direkt als AES-Schluessel verwenden oder nur einmal SHA-256 darueber laufen lassen, ist das kryptografisch schwach. Korrekt waere eine Key-Derivation-Function wie PBKDF2, scrypt oder Argon2 mit Salt und passenden Parametern. In Pentests tauchen solche Konstruktionen haeufig in Desktop-Tools, internen Skripten oder mobilen Apps auf, die "schnell" Daten verschluesseln sollen.

Auch Datenformat und Kontextbindung werden oft uebersehen. Wenn verschluesselte Daten keine Versionskennung, keinen Algorithmus-Identifier und keine Bindung an Kontextinformationen enthalten, entstehen Migrationsprobleme und Verwechslungsangriffe. Ein Token, das fuer einen Zweck erzeugt wurde, darf nicht stillschweigend in einem anderen Kontext akzeptiert werden. Gute Designs authentifizieren deshalb zusaetzliche Metadaten, etwa Benutzer-ID, Zweck, Ablaufzeit oder Protokollversion.

# Beispielhafte Denkpruefung bei symmetrischer Verschluesselung
# Nicht als fertige Implementierung verstehen

Fragen im Review:
1. Welcher Algorithmus und welcher Modus werden genutzt?
2. Gibt es Authentifizierung der Ciphertexts?
3. Wie werden IV oder Nonce erzeugt?
4. Kann ein Nonce unter gleichem Schluessel wiederverwendet werden?
5. Wie wird der Schluessel abgeleitet, gespeichert und rotiert?
6. Sind Kontextdaten an die Nachricht gebunden?
7. Wie verhaelt sich die Anwendung bei Entschluesselungsfehlern?

Wer Anwendungen testet, sollte deshalb nicht nur nach "AES vorhanden" suchen, sondern nach dem gesamten Lebenszyklus der Daten. Verschluesselung ist nur so stark wie die Implementierung drum herum. Das gilt besonders in Web- und API-Umgebungen, die in Web Application Hacking Einstieg und Burp Suite Fuer Anfaenger aus Angreifersicht weiter vertieft werden.

Asymmetrische Kryptografie wird in der Praxis vor allem fuer Authentisierung, Schluesselaustausch, Signaturen und Zertifikatsinfrastrukturen genutzt. RSA, ECDSA, Ed25519 und ECDH sind keine abstrakten Begriffe, sondern Bausteine von TLS, SSH, Code-Signing, S/MIME, VPNs und internen PKIs. Wer diese Mechanismen testet, muss weniger die Mathematik als die Vertrauenskette verstehen.

Ein Zertifikat ist im Kern nur eine signierte Bindung zwischen Identitaet und oeffentlichem Schluessel. Die Sicherheit entsteht durch die Frage, wem vertraut wird, wie diese Vertrauensentscheidung getroffen wird und ob die Anwendung die Kette korrekt validiert. Genau dort liegen viele reale Fehler: Hostname wird nicht geprueft, abgelaufene Zertifikate werden akzeptiert, Revocation wird ignoriert, selbstsignierte Zertifikate werden stillschweigend vertraut oder ein Debug-Flag deaktiviert die Pruefung komplett.

In internen Netzen ist die Lage oft noch schlechter. Unternehmen betreiben eigene CAs, verteilen Root-Zertifikate ueber GPOs oder MDM und verlieren den Ueberblick ueber Geltungsbereiche. Dann existieren Test- und Produktivzertifikate parallel, private Schluessel liegen auf Fileshares oder Service-Accounts duerfen Zertifikate fuer beliebige Hosts anfordern. Solche Fehler sind fuer Red Teams und Pentester extrem wertvoll, weil sie laterale Bewegung, TLS-Interception oder Identitaetsmissbrauch ermoeglichen.

Auch bei SSH zeigt sich das gleiche Muster. Der Algorithmus ist selten das Problem. Unsicher wird es, wenn Host Keys nicht verifiziert, private Keys ungeschuetzt gespeichert oder agent forwarding unkontrolliert genutzt werden. In Cloud-Umgebungen kommen kurzlebige Zertifikate, Secret Stores und automatisierte Rotation hinzu. Das verbessert Sicherheit nur dann, wenn Prozesse sauber umgesetzt sind. Automatisierung kompensiert keine falschen Vertrauensannahmen.

Ein Pentester sollte bei Zertifikaten immer mehrere Ebenen pruefen: technische Gueltigkeit, korrekte Bindung an den Dienst, Schluesselstaerke, Signaturalgorithmus, Kettenaufbau, Vertrauensanker und operative Prozesse. Ein formal gueltiges Zertifikat kann trotzdem ein Risiko sein, wenn der private Schluessel auf einem kompromittierbaren System liegt oder wenn dieselbe CA fuer zu viele Zwecke genutzt wird.

Gerade bei Webanwendungen lohnt sich die Verbindung zur Transport- und Session-Sicherheit. Ein unsauber validiertes Backend-Zertifikat kann interne API-Kommunikation kompromittieren, auch wenn die Frontend-Seite sauber aussieht. Solche Zusammenhaenge werden oft uebersehen, wenn nur Browserwarnungen statt echter Vertrauensmodelle betrachtet werden.

TLS ist fuer viele Teams gleichbedeutend mit Sicherheit. Diese Gleichsetzung ist gefaehrlich. HTTPS bedeutet nur, dass ein TLS-Kanal aufgebaut wurde. Ob dieser Kanal stark konfiguriert ist, korrekt validiert wird und sensible Daten wirklich schuetzt, ist eine andere Frage. In Assessments zeigt sich regelmaessig, dass TLS zwar vorhanden ist, aber falsch verstanden wird.

Ein typischer Fehler ist die Konzentration auf Cipher Suites, waehrend grundlegende Validierungsprobleme ignoriert werden. Wenn eine mobile App oder ein internes Tool Zertifikatswarnungen unterdrueckt, ist die staerkste Cipher Suite wertlos. Wenn Backend-Services Zertifikate nicht auf den Hostnamen pruefen, kann ein Angreifer mit einem beliebigen gueltigen Zertifikat fuer eine andere Domain unter Umstaenden den Verkehr abfangen. Wenn Session-Tokens nach erfolgreichem TLS-Aufbau ungeschuetzt in Logs, URLs oder Referrern landen, schuetzt der Transportkanal nur einen Teil des Weges.

Wichtig ist auch das Verstaendnis von Forward Secrecy. Moderne TLS-Konfigurationen nutzen ephemere Schluesselaustauschverfahren, damit ein spaeter kompromittierter Langzeitschluessel nicht alte Sitzungen entschluesseln kann. In sensiblen Umgebungen ist das kein Luxus, sondern Grundschutz. Ebenso relevant sind Protokollversionen, Downgrade-Schutz, HSTS, sichere Cookie-Flags und die Trennung zwischen externer und interner Transportabsicherung.

Bei Tests sollte nicht nur der oeffentliche Webserver betrachtet werden. Interne APIs, Admin-Panels, Message Queues, Datenbankverbindungen, SMTP-Relays und Service-Mesh-Kommunikation sind oft deutlich schwaecher abgesichert. Gerade dort finden sich veraltete Protokolle, selbstsignierte Zertifikate oder hart kodierte Trust Stores. Wer mit Wireshark Grundlagen arbeitet, erkennt schnell, ob Transportschutz konsistent umgesetzt wurde oder nur an sichtbaren Stellen existiert.

• Pruefen, ob Zertifikatsvalidierung wirklich aktiv ist und nicht durch Debug-Optionen umgangen wird.
• Pruefen, ob nur starke Protokollversionen und sinnvolle Cipher Suites aktiv sind.
• Pruefen, ob Session- und Authentisierungsdaten auch ausserhalb des TLS-Kanals sauber behandelt werden.

Ein weiterer Punkt ist TLS-Interception durch Proxys oder Sicherheitsprodukte. In Unternehmensnetzen kann das legitim sein, veraendert aber das Vertrauensmodell massiv. Anwendungen mit Certificate Pinning reagieren darauf anders als Standardbrowser. Aus Angreifersicht ist relevant, ob solche Interception-Infrastrukturen selbst sauber abgesichert sind. Ein kompromittierter Proxy mit Root-Vertrauen ist ein idealer Hebel fuer grossflaechige Man-in-the-Middle-Szenarien.

Transportverschluesselung ist also kein Haken auf einer Checkliste, sondern ein System aus Protokollparametern, Vertrauensbeziehungen und Anwendungslogik. Erst wenn diese Ebenen zusammen betrachtet werden, laesst sich das reale Risiko bewerten.

Wenn Angreifer an Passwortdaten gelangen, entscheidet nicht die Passwortpolicy allein ueber den Schaden, sondern die Qualitaet der Speicherung. Genau deshalb ist Passwort-Hashing eines der wichtigsten kryptografischen Themen im Pentest. Ein Datenbankdump mit Argon2id und starken Parametern ist ein anderes Risiko als ein Dump mit unsaltiertem SHA-1 oder MD5.

Offline-Angriffe sind fuer Verteidiger besonders unangenehm, weil sie ausserhalb der Zielumgebung stattfinden. Rate Limits, MFA, IP-Sperren und Monitoring helfen dann nicht mehr. Der Angreifer kann lokal mit GPU-Clustern, Wortlisten, Regelwerken und Hybridangriffen arbeiten. Deshalb muessen Passwort-Hashes absichtlich teuer sein. Genau das leisten Argon2, bcrypt und scrypt. Sie verlangsamen die Pruefung pro Kandidat und erschweren Massenangriffe erheblich.

Salts sind dabei Pflicht, aber kein Allheilmittel. Ein Salt verhindert vor allem Rainbow Tables und sorgt dafuer, dass gleiche Passwoerter nicht zu gleichen Hashes fuehren. Es ersetzt keine langsame Hashfunktion. Ebenso wird Pepper oft missverstanden. Ein serverseitiges zusaetzliches Geheimnis kann Schutz verbessern, aber nur wenn es getrennt verwaltet und nicht zusammen mit der Datenbank kompromittiert wird.

In Assessments tauchen immer wieder dieselben Fehler auf: schnelle Hashes fuer Passwoerter, fehlende oder globale Salts, abgeschnittene Hashes, proprietaere Konstruktionen, reversible "Verschluesselung" statt Hashing oder Legacy-Migrationen, bei denen alte schwache Hashes aus Kompatibilitaetsgruenden weiter akzeptiert werden. Besonders kritisch sind Systeme, die beim Login mehrere alte Verfahren nacheinander pruefen. Das vergroessert die Angriffsoberflaeche und verraet oft ueber Fehlermeldungen oder Timing, welcher Hash-Typ vorliegt.

Auch Passwort-Reset-Prozesse gehoeren in diesen Bereich. Ein stark gehashter Passwortspeicher hilft wenig, wenn Reset-Tokens vorhersagbar sind, zu lange gueltig bleiben oder nicht an den Benutzerkontext gebunden werden. In Webtests sollte deshalb immer die gesamte Authentisierungskette betrachtet werden: Registrierung, Login, Passwortwechsel, Reset, MFA-Enrollment, Session-Invalidierung und Audit-Logging. Das verbindet Kryptografie direkt mit Anwendungslogik und Themen aus Owasp Top 10 Erklaert.

# Beispiel fuer typische Review-Fragen bei Passwortspeicherung

- Welches Verfahren wird genutzt? Argon2id, bcrypt, scrypt oder etwas Eigenes?
- Gibt es pro Passwort einen individuellen Salt?
- Sind Kostenparameter an aktuelle Hardware angepasst?
- Werden Legacy-Hashes noch akzeptiert?
- Wie werden Passwort-Reset-Tokens erzeugt und invalidiert?
- Gibt es Hinweise auf Offline-Angriffe durch geleakte Dumps oder Backups?

Wer Passwortsicherheit bewertet, sollte immer den Angreifermodus mitdenken. Online-Bruteforce ist laut, langsam und sichtbar. Offline-Cracking ist leise, skalierbar und oft entscheidend fuer den realen Impact eines Datenabflusses.

In modernen Webanwendungen zeigt sich Kryptografie selten als eigenstaendiger Dienst, sondern eingebettet in Sessions, Tokens und API-Mechanismen. Genau deshalb werden Fehler oft uebersehen. Ein JWT mit starker Signatur kann trotzdem unsicher sein, wenn Claims zu viel verraten, Ablaufzeiten fehlen, Schluessel schlecht verwaltet werden oder die Anwendung den Token in unsicheren Kontexten akzeptiert.

JWTs werden haeufig missverstanden. Signierte JWTs sind standardmaessig nicht vertraulich. Jeder, der den Token sieht, kann die Base64-kodierten Claims lesen. Wenn dort Rollen, interne IDs, E-Mail-Adressen oder Berechtigungsinformationen stehen, ist das nicht automatisch kritisch, aber es muss bewusst entschieden werden. Problematisch wird es, wenn sensible Daten wie interne Pfade, Debug-Flags oder personenbezogene Informationen in Tokens landen, die ueber Browser, Logs oder Drittkomponenten wandern.

Historisch gab es bekannte Fehlerklassen wie "alg=none" oder Verwechslungen zwischen asymmetrischer und symmetrischer Verifikation. Heute sind Bibliotheken besser, aber Implementierungsfehler bleiben. Dazu gehoeren fehlende Pruefung von issuer und audience, zu grosszuegige clock skew, Akzeptanz abgelaufener Tokens, unsichere Key-Rotation oder die Nutzung eines einzigen Schluessels fuer mehrere Dienste mit unterschiedlichen Vertrauensstufen.

Bei Cookies ist die Lage aehnlich. Ein "verschluesseltes" Cookie muss nicht sicher sein, wenn Integritaet fehlt oder wenn der Schluessel in mehreren Umgebungen geteilt wird. Ein signiertes Cookie schuetzt nicht vor Informationsabfluss, wenn Inhalte lesbar bleiben. Und selbst ein korrekt geschuetztes Session-Cookie verliert an Wert, wenn HttpOnly, Secure oder SameSite falsch gesetzt sind oder wenn Session-Fixation moeglich bleibt.

API-Signaturen sind ein weiteres Feld fuer echte Praxisfehler. Viele interne APIs bauen HMAC-basierte Signaturen ueber Request-Parameter. Unsicher wird das, wenn Parameter nicht kanonisch sortiert, Header nicht einbezogen, Zeitfenster zu gross oder Nonces nicht serverseitig verfolgt werden. Dann sind Replay-Angriffe oder Signaturumgehungen moeglich. In Burp lassen sich solche Muster gut analysieren, insbesondere wenn Requests systematisch veraendert und Signaturfehler beobachtet werden. Vertiefend dazu passen Web Security Lernen und Burp Suite Fuer Anfaenger.

Ein erfahrener Tester betrachtet deshalb nicht nur den Token selbst, sondern den gesamten Lebenszyklus:

• Wie wird der Token erzeugt, signiert, gespeichert, uebertragen und invalidiert?
• Welche Claims oder Metadaten sind enthalten und welche Vertrauensannahmen haengen daran?
• Kann ein Token in einem anderen Kontext, fuer einen anderen Dienst oder nach Logout weiterverwendet werden?

Gerade in Microservice-Architekturen entstehen hier komplexe Fehler. Ein Frontend validiert vielleicht korrekt, ein internes Backend akzeptiert aber denselben Token ohne audience-Pruefung. Oder ein Gateway terminiert TLS sauber, waehrend dahinter interne Dienste Header blind vertrauen. Kryptografie ist dann nur ein Teil des Problems; der Rest ist Architektur.

Die meisten kritischen Kryptografie-Befunde in realen Projekten sind banal und gleichzeitig verheerend. Nicht weil die Mathematik schlecht waere, sondern weil Prozesse, Bibliotheken oder Annahmen falsch sind. Ein Klassiker sind schwache Zufallszahlen. Wenn Session-IDs, Reset-Tokens, API-Keys oder Nonces aus vorhersagbaren Quellen stammen, ist der Rest des Designs oft irrelevant. Pseudozufall aus Zeitstempeln, linearen Generatoren oder schlecht initialisierten PRNGs fuehrt direkt zu Kontouebernahmen oder Schluesselkompromittierung.

Ebenso haeufig sind Key-Leaks. Private Schluessel liegen in Git-Repositories, Container-Images, CI-Logs, Backup-Archiven, mobilen Apps oder Konfigurationsdateien. In Cloud-Umgebungen werden Secrets oft in Umgebungsvariablen oder Build-Artefakten repliziert und dadurch unkontrolliert verbreitet. Ein Pentester sollte deshalb nie nur die laufende Anwendung betrachten, sondern auch Deployment-Pfade, Artefakte und Historien. Themen wie saubere Linux- und Dateisystemanalyse spielen dabei eine grosse Rolle, etwa in Linux Fuer Hacker und Kali Linux Linux Tools Uebersicht.

Besonders gefaehrlich ist kryptografischer Eigenbau. Entwickler kombinieren Hashes, XOR, Base64, Zeitstempel und "geheime" Konstanten zu proprietaeren Verfahren, die wie Verschluesselung aussehen sollen. Solche Konstruktionen scheitern fast immer an fehlender Integritaet, schlechter Schluesseltrennung, Wiederverwendung oder trivialer Rueckrechenbarkeit. Im Bericht sollte dann nicht nur "Custom Crypto" stehen, sondern konkret, welche Sicherheitsziele verfehlt werden und wie ein Angreifer das ausnutzt.

Ein weiterer Fehler ist das falsche Bedrohungsmodell. Teams schuetzen Daten im Ruhezustand, ignorieren aber den Zugriffspfad ueber die Anwendung. Oder sie investieren in starke Transportverschluesselung, waehrend Logs Klartextdaten enthalten. Oder sie signieren Requests, ohne Replay-Angriffe zu bedenken. Kryptografie loest immer nur ein klar definiertes Problem. Wenn das Problem falsch formuliert ist, entsteht Scheinsicherheit.

Auch Seiteneffekte verdienen Aufmerksamkeit. Timing-Unterschiede bei Token-Vergleichen, unterschiedliche Fehlermeldungen bei Entschluesselung, detailreiche Stacktraces oder Debug-Endpunkte koennen kryptografische Schutzmechanismen unterlaufen. Solche Leaks sind oft klein, aber in Kombination mit anderen Schwachstellen hochrelevant. Genau hier zeigt sich die Verbindung zwischen Kryptografie, sicherer Implementierung und allgemeiner Angriffslogik.

In der Praxis lohnt sich deshalb ein skeptischer Blick auf jede Stelle, an der "Security" behauptet wird. Wenn ein Produkt mit "military-grade encryption" wirbt, ist das kein Sicherheitsbeweis. Entscheidend sind Schluesselherkunft, Trust Boundaries, Fehlerverhalten, Rotation, Logging, Recovery-Prozesse und die Frage, ob Standardbibliotheken korrekt eingesetzt werden.

Kryptografische Befunde werden in Berichten oft entweder dramatisiert oder verharmlost. Beides ist unprofessionell. Ein belastbarer Workflow trennt Beobachtung, technische Auswirkung, Ausnutzbarkeit und Geschaeftsrisiko sauber voneinander. "Veralteter Algorithmus" allein ist noch kein kritischer Befund. "Vorhersagbare Reset-Tokens erlauben Kontouebernahme" dagegen ist ein klarer Angriffspfad.

Am Anfang steht die Bestandsaufnahme. Welche kryptografischen Funktionen existieren ueberhaupt? Welche Bibliotheken, Protokolle, Zertifikate, Tokenformate und Schluesselquellen werden genutzt? Danach folgt die Kontextanalyse: Welche Daten werden geschuetzt, gegen wen, in welchem Lebenszyklus und mit welchen Vertrauensannahmen? Erst dann lohnt sich die technische Tiefenpruefung.

Bei der Verifikation sollte reproduzierbar gearbeitet werden. Wenn ein JWT-Problem vermutet wird, werden Header, Claims, Signaturpruefung, Key-Rotation und Akzeptanzregeln systematisch getestet. Bei TLS werden nicht nur Scanner-Ergebnisse gesammelt, sondern konkrete Verbindungswege, Hostname-Pruefung, Zertifikatsketten und Client-Verhalten dokumentiert. Bei Passwort-Hashing werden Verfahren, Parameter, Salt-Strategie und Migrationslogik bewertet. Das Ziel ist immer ein nachvollziehbarer Nachweis, kein Sammelsurium aus Tool-Ausgaben.

Wichtig ist auch die Priorisierung. Ein interner Dienst mit selbstsigniertem Zertifikat in einem streng segmentierten Netz ist anders zu bewerten als dieselbe Fehlkonfiguration in einer mobilen App mit deaktivierter Zertifikatspruefung. Ein SHA-1-Fingerprint in einer Alt-Dokumentation ist kein Incident. Ein produktiver Signaturmechanismus auf Basis von SHA-1 kann dagegen relevant sein, je nach Einsatzkontext. Gute Bewertung bedeutet, technische Tiefe mit realistischer Angreiferperspektive zu verbinden.

Im Reporting muessen Empfehlungen konkret sein. Nicht "modernere Kryptografie verwenden", sondern etwa: Argon2id mit definierten Parametern einfuehren, AEAD statt CBC ohne MAC nutzen, Zertifikatsvalidierung inklusive Hostname-Pruefung erzwingen, Schluessel in einem Secret-Management-System speichern, Replay-Schutz fuer API-Signaturen implementieren, Legacy-Hashes bei erfolgreichem Login migrieren und alte Verfahren abschalten. Wer Berichte strukturiert aufbauen will, findet angrenzende Methodik in Pentesting Vorgehensweise und Pentesting Bericht Schreiben.

# Minimaler Workflow fuer Crypto-Befunde

1. Asset und Datenfluss identifizieren
2. Sicherheitsziel bestimmen: Vertraulichkeit, Integritaet, Authentizitaet, Nichtabstreitbarkeit
3. Eingesetzte Primitive und Bibliotheken erfassen
4. Schluesselmanagement und Trust Boundaries analysieren
5. Implementierung und Fehlerverhalten testen
6. Praktische Ausnutzbarkeit nachweisen
7. Risiko im Kontext priorisieren
8. Konkrete Remediation formulieren

Wer so arbeitet, liefert keine abstrakten Kryptografie-Notizen, sondern verwertbare Sicherheitsbefunde mit technischer Substanz. Genau das ist in professionellen Assessments entscheidend.