Warum waechst Cost exponentiell, nicht linear?

Weil es **2^cost Iterationen der inneren Blowfish-Funktion** sind. Cost 10 = 2^10 = 1024 Iterationen, Cost 11 = 2048, Cost 12 = 4096. Jedes +1 verdoppelt die Zeit. Fuer Angreifer gleiches Wachstum: **Cost 12 ist 16x schwerer zu cracken als Cost 8**.

Warum nicht einfach MD5 oder SHA-256?

**Weil sie zu schnell sind**. Eine NVIDIA RTX 4090 GPU rechnet ~100 Milliarden MD5/s, ~10 Milliarden SHA-256/s. Brute-forced "Sommer2024!" in einer Sekunde. bcrypt mit Cost 12 auf gleicher GPU: ~10.000 Versuche/s, **eine Million Mal langsamer**. **Jede moderne App nutzt bcrypt, Argon2 oder scrypt**, nie plain SHA-256 fuer Passwoerter.

bcrypt vs. Argon2, was ist besser?

**Argon2id** ist der moderne Gewinner der [[Password Hashing Competition||Industrie-Wettbewerb 2013-2015, der den bcrypt-Nachfolger waehlte]] (2015). Hat **Memory-Hardness** (besiegt GPU/ASIC-Attacken). **Fuer neue App: Argon2id** (OWASP-Empfehlung). bcrypt **ist immer noch ok** fuer existierende Apps und Oekosysteme ohne Argon2-Unterstuetzung. Nie plain SHA.

Kann ich den Benchmark mehrmals laufen lassen?

Ja, jeder Run ist eine **frische Messung**. Zahlen koennen +/-10% wackeln durch CPU-Throttling, andere Apps etc. **Median aus 3 Runs** filtert das meiste Rauschen. Fuer beste Genauigkeit: andere Tabs zu, Laptop ans Stromnetz, 2-3 mal laufen lassen.

Warum ist Cost 14 in Chrome langsamer als Firefox?

Andere **JavaScript-Engines** (V8 vs. SpiderMonkey) optimieren bcrypt unterschiedlich. Unterschied **vernachlaessigbar**: beide haben die gleiche exponentielle Form. In Production laufen bcrypt meist **server-seitig** (Node.js, Python, Ruby...), der Browser-Benchmark ist ein **Proxy fuer Groessenordnung**.

Cost 31 ist Maximum, warum nicht einfach das?

Weil Cost 31 = **2^31 = 2,1 Milliarden Iterationen** = auf modernem CPU **ueber 30 Minuten fuer einen Hash**. User-Logins wuerden eine halbe Stunde dauern. Praktisches Max ist **Cost 16-17** (paar Sekunden). Drueber flirtest du mit Denial-of-Service via Login.

Aendert sich der bcrypt-Hash jedes Mal?

**Ja, gleiches Passwort gibt anderen Hash bei jedem Aufruf**. Weil bcrypt **automatisch ein Random-Salt** generiert und in den Output einbettet. Format: `$2b$12$ `. Zwei User mit Passwort "qwerty123" kriegen **verschiedene Hashes**, ein Angreifer, der die DB liest, sieht nicht, dass sie gleich sind.

Warum stoppt der Benchmark bei Cost 14, nicht 31?

Weil Cost 15+ **15+ Sekunden im Browser** dauert und die UI zu lang einfrieren wuerde. **Cost 14 (~150 ms) ist die praktische Obergrenze** fuer typische Web-Apps. Drueber wechselst du normal zu Argon2 mit Memory-Parametern.

Was bedeutet "$2b$" am Anfang des Hashes?

Das ist die **Algorithmus-Version** von bcrypt. **$2b$** ist modern (seit 2014, Null-Byte-Bug gefixt). $2a$ ist aelter (1999, in PHP beliebt, hatte Special-Char-Bug). $2y$ ist eine PHP-only-Variante. Jede moderne Library (bcryptjs, bcrypt.js in Node) nutzt **$2b$**.

YourDevToolsPro

bcrypt Cost-Analyzer

Finde den bcrypt-Cost-Faktor, der zu deiner Hardware passt. OWASP empfiehlt 250-500 ms pro Hash.

LiveLäuft im Browser

bcrypt Cost-Faktor analysieren

Finde den besten bcrypt-Cost-Faktor für deine Hardware. Der Benchmark hasht ein Beispielpasswort mit Cost 4-14 und empfiehlt den höchsten Wert im OWASP-Fenster von 250-500 ms.

Der Benchmark hasht ein Beispielpasswort mit Cost 4, 6, 8, 10, 12, 14 (jeweils drei Durchläufe, Median). Dauert je nach Hardware ~5-15 Sekunden.

Schnelltest: echtes Passwort hashen

Tippe ein Passwort und wähle einen Cost-Faktor, um die genaue Zeit + den erzeugten bcrypt-Hash auf diesem Gerät zu sehen.

Kosten10

Das Hashen passiert lokal. Das Test-Passwort verlässt deinen Browser nie.

Was ist der bcrypt-Cost-Faktor und warum wichtig?

bcrypt ist seit ueber 20 Jahren Industriestandard. Jeder Login in deiner App ist ein Passwort-Hash + Vergleich mit DB. Je langsamer der Hash, desto schwerer fuer Angreifer, Passwoerter durch Millionen Kombinationen zu raten. Der "Cost-Faktor" ist der Parameter, der Compute-Zeit exponentiell skaliert.

Cost 10 = ~10 ms pro Hash (schnelle Hardware, schneller Login). Cost 12 = ~40 ms. Cost 14 = ~160 ms. Cost 16 = >0,5 s (spuerbar langsamer Login). Trade-off: zu niedrig = einfacher Brute-Force. Zu hoch = schlechte UX und hoehere Server-Kosten.

OWASP empfiehlt 2025: 250-500 ms pro Hash auf Production-Hardware anstreben. Lass den Benchmark hier laufen, sieh den Cost-Faktor, der in dem Fenster landet.

Alles laeuft lokal. Dein Test-Passwort verlaesst den Browser nie.

So nutzt du das Tool

Klick Benchmark starten. Das Tool hashed ein Sample-Passwort mit Cost-Faktoren 4, 6, 8, 10, 12, 14 (je dreimal).
Sekunden spaeter siehst du das Diagramm: Y-Achse Millisekunden, jeder Balken ein anderer Cost. Balken wachsen exponentiell (jeder Cost ist 2x langsamer als der vorherige).
Empfehlung: der hoechste Cost, der noch ins 250-500-ms-Fenster passt (gruener Balken). Diese Zahl in die App-Config.
Drunter: Quick-Test laesst dich jedes Passwort mit jedem Cost hashen und siehst exakte Zeit + bcrypt-Hash fuer dieses Passwort auf diesem Geraet.
Merke: Cost auf deinem Laptop ist nicht Cost auf dem Production-Server. Benchmark auf der echten Hardware, wo die App laufen soll.

Wann nutzen

Fuenf Situationen, in denen ein Cost-Analyzer hilft:

Cost fuer neue App waehlen. Du hashst Passwoerter zum ersten Mal, brauchst einen Cost. Benchmark sagt: auf diesem VPS ist Cost 12 = 280 ms, perfekt.
Auf staerkeren Cost migrieren. App nutzt seit 3 Jahren Cost 10, Zeit zum Hochstellen. Benchmark zeigt Cost 13 ist auf neuen Servern nur noch 200 ms.
Langsame Logins diagnostizieren. User beklagen 2-Sekunden-Logins. Benchmark: ah, Team hat Cost 16 gesetzt, viel zu hoch fuer diese Maschine.
Hardware-Vergleich. Alter Server vs. neue AWS-Instanz, welchen Cost kannst du dir leisten?
Team-Schulung. Zeig einem Junior, wie der Cost-Faktor funktioniert und warum MD5 nicht reicht.

Fuer andere Hashes (SHA-256, MD5, Argon2) den Passwort-Hash-Generator. Fuer Passwort-Leak-Check Pwned Passwords.

Fragen und Antworten

OWASP 2025: 250-500 ms pro Hash. Cost 10 auf modernem Laptop ~10 ms (zu schnell, Brute-Force-anfaellig). Cost 12 ~40 ms (besser). Cost 13-14 ~200-500 ms (ideal). Auf schwaecherem Server kann Cost 12 schon im Zielfenster sein. Benchmark auf deiner Hardware.

Das könnte auch passen

Passende Tools

Passwort-Hashes: MD5, SHA, bcrypt

16 Hash-Algorithmen: MD4, MD5, SHA, SHA-3, RIPEMD, MySQL, NTLM, HMAC, bcrypt - mit optionalem Salt.

bcrypt prüfen

Prüfe, ob ein Passwort zu einem bcrypt-Hash passt. Match oder Mismatch in Sekunden.

Passwort-Generator

Erstelle starke, kryptografisch zufällige Passwörter - komplett im Browser.

JWT signieren / verifizieren

Ein JWT mit Secret oder Private Key signieren. Ein bestehendes Token verifizieren. HS/RS/ES/PS 256/384/512.

AES Verschlüsseln / Entschlüsseln

Text mit Passwort verschlüsseln (AES-GCM 256). Läuft im Browser, nichts verlässt das Gerät.