Passwort vs UUID vs Hash vs Token: Ein Entwickler-Guide zu 8 Arten zufälliger Zeichenketten

In der Softwareentwicklung begegnen einem ständig Zeichenketten wie 550e8400-e29b-41d4-a716-446655440000 oder eyJhbGciOiJIUzI1NiJ9... — zufällig wirkende Zeichenfolgen. UUIDs, Passwörter, Hashes, Tokens, API-Schlüssel… sie sehen alle ähnlich aus, doch ihre Designabsicht und ihr Zweck unterscheiden sich grundlegend.

Dieser Artikel schlüsselt die 8 häufigsten Arten zufällig wirkender Zeichenketten danach auf, „warum sie existieren“ und „was sie schützen“. Sobald du verstehst, was jede wirklich ist, wird die Wahl der richtigen für jede Situation zur Selbstverständlichkeit.

Vergleich aller 8 Arten

Beginnen wir mit dem Gesamtbild.

Art	Hauptzweck	Geheim?	Umkehrbar?	Erzeugung	Schlüsselmerkmal
UUID	Eindeutige Identifikation	Nein	—	Zufall / Zeit	Kollisionsfreie ID
Passwort	Benutzer-Authentifizierung	Ja	Nur Eigentümer	Vom Menschen erstellt	Gemerktes Geheimnis
Hash	Integritätsprüfung	Nein	Irreversibel	Mathematische Funktion	Digitaler Fingerabdruck
Token	Authentifizierung / Autorisierung	Ja	Kommt darauf an	CSPRNG	Läuft ab
API-Schlüssel	Dienst-Authentifizierung	Ja	—	CSPRNG	Maschinen-Passwort
Salt	Hash-Härtung	Nein	—	CSPRNG	Schutz vor Rainbow Tables
Nonce	Einmal-Identifikation	Nein	—	CSPRNG	Replay-Schutz
Signatur	Manipulationserkennung	Nein	Irreversibel	Krypto-Berechnung	HMAC, RSA-Signatur

Die zentrale Erkenntnis: nach Designzweck klassifizieren, nicht nach Aussehen. Dieselbe 32 Zeichen lange Zufallskette kann ein bloßes Etikett sein, wenn sie als UUID dient, oder ein Authentifizierungsschlüssel, wenn sie als Token dient.

UUID — Ein kollisionsfreies Etikett

Eine UUID (Universally Unique Identifier) existiert, um IDs zu erzeugen, die nicht kollidieren — weltweit, ohne Abstimmung. Sie hat nichts mit Sicherheit zu tun; ihre einzige Aufgabe ist die Identifikation.

Die am weitesten verbreitete Variante, UUID v4, wird zufällig mit 122 Bit Entropie erzeugt. Das sind rund 5,3 × 10³⁶ mögliche Werte — selbst wenn du eine Milliarde pro Sekunde erzeugst, würdest du über 10 Milliarden Jahre auf eine Kollision warten.

Häufige Anwendungsfälle:

• Primärschlüssel in Datenbanken (Alternative zum Auto-Increment)
• Eindeutige Objekt-IDs in verteilten Systemen
• Kollisionsfreie Dateinamen für Uploads
• Request-IDs für Tracing und Logging

→ Probiere und lerne mit unserem kostenlosen UUID-Generator

Passwort — Das einzige vom Menschen verwaltete Geheimnis

Unter allen 8 Arten sind Passwörter die einzigen, die für die menschliche Merkfähigkeit konzipiert sind. Dadurch hängt ihre Entropie zwangsläufig vom menschlichen Gedächtnis ab — und ist daher schwächer als maschinell erzeugte Alternativen.

Genau deshalb erfordern Passwörter eine besondere Behandlung bei der Speicherung. Sie im Klartext zu speichern ist inakzeptabel. Sie müssen gehasht werden, und zwar nicht mit irgendeinem Hash — die moderne Best Practice verlangt bewusst langsame Algorithmen wie bcrypt, Argon2 oder scrypt.

Warum ist „langsam“ wichtig? Wenn ein Angreifer bei einem Brute-Force-Angriff Milliarden von Hash-Berechnungen pro Sekunde versucht, erhöht ein Algorithmus, der 0,1 Sekunden pro Berechnung braucht, die Angriffskosten um Größenordnungen.

Häufige Anwendungsfälle:

• Login-Authentifizierung bei Webdiensten
• Zugangsdaten für SSH und Datenbanken
• Verschlüsselungs-Passphrasen für Dateien

→ Probiere und lerne mit unserem kostenlosen Passwort-Generator

Hash — Ein digitaler Fingerabdruck

Eine Hash-Funktion nimmt eine Eingabe beliebiger Länge und erzeugt eine Ausgabe fester Länge — eine Einweg-Transformation. Dieselbe Eingabe liefert immer dieselbe Ausgabe, aber du kannst sie nicht zurückrechnen. Stell sie dir als Fingerabdruck von Daten vor.

SHA-256 etwa komprimiert sowohl ein 5 Zeichen langes „hello“ als auch eine 1 GB große Datei auf einen 256-Bit-Wert (64 Hexadezimalzeichen). Ändere auch nur ein Bit der Originaldaten, und der Hash ändert sich vollständig.

Häufige Anwendungsfälle:

• Passwortspeicherung — Den Hash statt des Klartexts speichern
• Datei-Integritätsprüfung — Prüfen, ob Downloads unverändert sind (Prüfsummen)
• Git-Commit-IDs — Git verwaltet jeden Commit mit SHA-1-Hashes
• Blockchain — Transaktionsketten werden durch Hashes gesichert

→ Probiere und lerne mit unserem kostenlosen Hash-Generator

Token — Ein temporärer Passierschein

Ein Token beweist „diese Person ist authentifiziert“ — vorübergehend. Nach einem erfolgreichen Login stellt der Server ein Token aus; nachfolgende Anfragen enthalten dieses Token, um zu behaupten „ich bin bereits authentifiziert“.

Das bekannteste Beispiel ist das JWT (JSON Web Token), das aus drei Base64-codierten Teilen besteht: Header, Payload und Signatur. Der Payload enthält die Benutzer-ID und die Ablaufzeit, und die Signatur erkennt Manipulationen.

Häufige Anwendungsfälle:

• Sitzungsverwaltung von Web-Apps
• OAuth-2.0-Access- und Refresh-Tokens
• Einmal-Links für E-Mail-Verifizierung und Passwort-Zurücksetzung
• Zustandslose (stateless) Authentifizierung in SPAs

→ Probiere und lerne mit unserem kostenlosen Token-Generator

API-Schlüssel — Ein Passwort für Maschinen

Ein API-Schlüssel ist eine Zeichenkette, mit der eine Anwendung oder ein Dienst sagen kann „ich bin ein autorisierter Nutzer“. Er wird nicht von einem Menschen eingetippt — er ist im Code eingebettet und wird an Anfragen angehängt.

Der größte Unterschied zu Passwörtern: niemand muss ihn sich merken. Das erlaubt die Erzeugung ausreichend langer Zufallsketten (128–256 Bit), was sie deutlich stärker macht. Der Haken: Sie bleiben oft im Klartext im Quellcode oder in Konfigurationsdateien und bergen so ein hohes Leck-Risiko.

Häufige Anwendungsfälle:

• Authentifizierung externer APIs (Google Maps, OpenAI, Stripe)
• Interne Dienst-zu-Dienst-Authentifizierung in Microservices
• Identifikation für Abrechnung und Rate-Limiting

→ Probiere und lerne mit unserem kostenlosen API-Schlüssel- und Token-Generator

Salt, Nonce und Signatur — Die Spezialisten im Hintergrund

Diese drei treten selten allein auf — sie sind Bausteine, die andere Mechanismen verstärken.

Salt

Ein Salt ist ein zufälliger Wert, der beim Hashen von Passwörtern pro Nutzer hinzugefügt wird. Selbst wenn zwei Nutzer das Passwort „password123″ teilen, erzeugen unterschiedliche Salts unterschiedliche Hashes. Das vereitelt Rainbow-Table-Angriffe — vorberechnete Hash-Wörterbücher.

Salts müssen nicht geheim sein — sie werden zusammen mit dem Hash in der Datenbank gespeichert. Moderne Algorithmen wie bcrypt und Argon2 übernehmen die Erzeugung und Verwaltung des Salts intern, sodass Entwickler sich selten manuell darum kümmern müssen.

Nonce

Nonce steht für „Number used ONCE“ — ein Einwegwert. Sein Hauptzweck ist die Abwehr von Replay-Angriffen. Fängt ein Angreifer eine Anfrage ab und sendet sie erneut, erkennt der Server, dass die Nonce bereits verwendet wurde, und weist sie ab.

In der Webentwicklung werden Nonces auch als CSRF-Schutz-Tokens (Cross-Site Request Forgery) verwendet. WordPress‘ wp_nonce_field() ist ein bekanntes Beispiel.

Signatur

Eine Signatur beweist, dass Daten nicht manipuliert wurden. HMAC (Hash-based Message Authentication Code) kombiniert einen geheimen Schlüssel mit einer Nachricht, um einen Hash zu berechnen. Ohne den geheimen Schlüssel kann ein Dritter keine gültige Signatur erzeugen — der Empfänger kann also bestätigen, dass die Daten von einem legitimen Absender stammen.

Das alg: HS256 in einem JWT-Header bedeutet „mit HMAC-SHA256 signiert“. Auch API-Webhooks (Stripe, GitHub usw.) nutzen HMAC-Signaturen zur Manipulationserkennung des Request-Bodys.

Ordnung nach Design-Achsen

Statt jede Art einzeln auswendig zu lernen, ordne sie entlang von 5 Achsen.

Art	Geheim?	Wiederherstellbar?	Eindeutigkeit kritisch?	Läuft ab?	Menschliche Nutzung?
UUID	×	×	◎	×	×
Passwort	◎	◎ (nur Eigentümer)	△	×	◎
Hash	×	× (irreversibel)	△	×	×
Token	◎	△	◎	◎	×
API-Schlüssel	◎	×	◎	△	×
Salt	×	×	△	×	×
Nonce	×	×	◎	◎	×
Signatur	×	× (irreversibel)	—	—	×

Beachte, dass nur Passwörter ein ◎ bei „Menschliche Nutzung“ haben. Das verdeutlicht, wie sehr Passwörter unter all diesen Zeichenketten-Arten ein grundsätzlicher Sonderfall sind.

In Angriffsmodellen denken

Im Sicherheitsdesign lautet die Leitfrage nicht „was schützen wir?“, sondern „welchen Angriff verhindern wir?„. Jede Zeichenketten-Art ist einer anderen Bedrohung ausgesetzt.

Art	Zu verhindernder Angriff	Verteidigungsstrategie
UUID	Kollision (doppelte IDs)	Genug Entropie, um Kollisionen vernachlässigbar zu machen
Passwort	Brute Force / Wörterbuch	Langsames Hashing + Salt + lange Passwörter
Hash	Preimage- / Kollisionsangriff	Sichere Algorithmen verwenden (SHA-256+)
Token	Replay / Abfangen	Kurzes TTL + HTTPS + Refresh-Rotation
API-Schlüssel	Leck	Umgebungsvariablen + Rotation + IP-Beschränkungen
Nonce	Replay	Einmalige Nutzung + serverseitiges Tracking
Signatur	Manipulation	Strenge Verwaltung des geheimen Schlüssels

Für UUIDs brauchst du keine Brute-Force-Resistenz, und um Kollisionsresistenz bei Passwörtern sorgst du dich selten. Unterschiedliche Bedrohungen erfordern unterschiedliche Designs.

Ein praktischer Entscheidungsweg

Wenn du unsicher bist, welche Art du verwenden sollst, folge diesem Gedankengang:

1. Den Zweck festlegen — Identifikation? Authentifizierung? Verifikation? Temporär?
2. Die Bedrohung bestimmen — Kollision? Erraten? Leck? Replay? Manipulation?
3. Die nötige Entropie ermitteln — 122 Bit für UUID, 256 Bit für Tokens
4. Die Erzeugungsmethode wählen — Math.random() ist nie in Ordnung; verwende crypto-Module
5. Über die Speicherung entscheiden — Klartext OK? Gehasht? Verschlüsselt? Umgebungsvariable?

Punkt 4 ist entscheidend. Standard-Zufallsgeneratoren (Math.random(), random.random()) sind nicht kryptografisch sicher. Verwende für jede sicherheitsrelevante Zeichenkette immer einen CSPRNG (kryptografisch sicheren Pseudozufallszahlengenerator). In Python ist das das Modul secrets; in Node.js crypto.randomBytes().

Zusammenfassung

Nach Designzweck gruppiert, fallen die 8 Arten in 4 Kategorien:

• Identifikation: UUID
• Authentifizierung: Passwort, API-Schlüssel
• Verifikation: Hash, Signatur
• Temporäre Authentifizierung / Abwehr: Token, Nonce, Salt

Sie mögen identisch aussehen, doch ihr Designzweck ist völlig verschieden — das ist die Kernbotschaft dieses Artikels.

Mach dir als Entwickler dieses Prinzip zu eigen: „Schau nicht auf die Zeichenkette — schau auf den Zweck.“ Ob du eine neue Zufallskette entwirfst oder mit einer bestehenden arbeitest, frage dich immer zuerst „was wird hier geschützt?“. Die richtige Erzeugungsmethode, der richtige Speicheransatz und die richtige Ablaufrichtlinie ergeben sich dann von selbst.