bcrypt-generator

bcrypt is nog steeds een van de veiligste keuzes voor het opslaan van wachtwoorden. Het is bewust traag, maakt zijn eigen salt en schaalt mee met hardwareverbeteringen via een instelbare costparameter. Deze generator maakt een standards-compliant bcrypt-hash van een plaintext wachtwoord, zodat je een testgebruiker kunt seeden, een account tussen systemen kunt migreren of waarden kunt vergelijken met een bestaande hash in een users.password-kolom.

Een wachtwoord hashen met bcrypt

  1. 1

    Voer het plaintext wachtwoord in

    Tot 72 bytes: bcrypt kapt alles daarna stilzwijgend af.

  2. 2

    Kies een costfactor

    12 is hier de default; 10 is een snellere legacy-keuze; 13 is de sterkste instelling van dit hulpmiddel. Elke +1 verdubbelt grofweg de hashtijd.

  3. 3

    Er wordt een random salt gegenereerd

    16 bytes salt worden uit een cryptografische RNG gehaald en ingebed in de resulterende hashstring.

  4. 4

    Kopieer de hash

    De uitvoer is een zelfbeschrijvende string zoals `$2b$12$...` met versie, cost, salt en digest.

Anatomie van een bcrypt-hash

$2b$12$mE2n5YqWjKqT9tXg.OQPoeeHZJ9hdSvOt5wFdRRQwl6yE1vWWY3z6
  |   |  |                      |
  |   |  salt (22 Base64 chars)  digest (31 Base64 chars)
  |   cost (2 digits, 4-31)
  version (2a, 2b, 2y, all bcrypt)

De volledige string is 60 tekens. Kolommen van het type VARCHAR(60) of CHAR(60) zijn het standaardschema.

Aanbevelingen voor costfactor

Cost Geschatte tijd per hash (2024 CPU) Gebruik
10 ~80 ms Legacy default, nog acceptabel
12 ~300 ms Huidige aanbevolen basislijn
13 ~600 ms Apps met hogere beveiliging
14 ~1.2 s Buiten het bereik van dit hulpmiddel (maximaal 13)

Elke stap verdubbelt de work factor. Als loginlatentie onder 500 ms kritisch is, blijf dan bij 10-12.

Versiebyte: 2a vs 2b vs 2y

  • $2a$, Oorspronkelijke specificatie uit 1999. De meeste libraries geven 2a-hashes uit.
  • $2b$, Revisie uit 2014 die een truncatiebug in crypt_blowfish oplost. Voorkeur voor nieuwe hashes.
  • $2y$, PHP-specifieke tag, functioneel gelijk aan $2b$.

Alle drie verifieren onderling; alleen de tag in de hashstring verschilt.

Waar bcrypt tegen beschermt

  • Rainbow tables, Unieke salt per hash verslaat vooraf berekende lookups.
  • GPU/ASIC-kraken, Het Blowfish keyschedule is memory-bound en onvriendelijk voor GPU’s. Niet zo GPU-onvriendelijk als Argon2, maar nog steeds traag om brute force op te doen.
  • Databaselekken, De plaintext is nooit uit de hash terug te halen zonder brute force.

Waar bcrypt NIET tegen beschermt: zwakke wachtwoorden (gebruik een minimumlengte en check tegen breach lists), credential stuffing (gebruik een tweede factor), phishing.

72-byte limiet

bcrypt gebruikt alleen de eerste 72 bytes van het wachtwoord. Langere invoer wordt stilzwijgend afgekapt, dezelfde reden waarom veel libraries nu aanraden het wachtwoord eerst met SHA-256 te pre-hashen voordat je het aan bcrypt geeft. Moderne alternatieven (Argon2, scrypt) hebben die limiet niet.

Veelgestelde vragen

Ja voor wachtwoordopslag, bij cost ≥ 12. OWASP noemt het nog steeds een acceptabel algoritme. Argon2id heeft de voorkeur voor nieuwe systemen, maar legacy bcrypt-hashes migreren heeft lage prioriteit.

Omdat de salt per hash random wordt gegenereerd. Verificatie haalt de salt uit de opgeslagen hash, hasht het ingevoerde wachtwoord daarmee opnieuw en vergelijkt.

De meeste libraries bieden dit niet aan, en met reden, voorspelbare salts ondermijnen het doel. Gebruik de salt die de library genereert; dat is het veilige pad.

Elke +1 verdubbelt grofweg de hashtijd, dus cost 13 duurt ongeveer 8x langer dan cost 10. Blijf binnen 10-12, tenzij je applicatie de extra sterkte echt nodig heeft.

Gerelateerde tools

Tool beschikbaar in andere talen