Hoe Bcrypt werkt: zout, kostenfactor en limieten

De eerste keer dat ik een inlogsysteem verscheepte, deed ik het ding dat elke tutorial uit die tijd me opdroeg: opgeslagen md5($password) in de gebruikerstabel en verder. 't Werd, en het was stilletjes een ramp Jarenlang auth in WordPress plugins en Laravel apps bouwen later, heb ik een veel gezonder respect voor de kloof tussen & quot; de wachtwoordcontrole passeert" en & quot; de wachtwoorden zijn veilig als deze database lekt." Bcrypt is de tool die het grootste deel van die kloof dicht, en het is de standaard in bijna elk framework waar ik naar reik Dus heb ik een bcrypt generator in Toolz.dev dat hashes een wachtwoord met een kostenfactor die u beheert, verifieert een wachtwoord tegen een bestaande hash, en doet alles in uw browser zodat niets dat u typt ooit ergens naartoe wordt verzonden Dit is de gids voor het en om zichzelf te bcrypten.

tl;dr: Bcrypt verandert een wachtwoord in een gezouten, opzettelijk langzame hash van 60 tekens, zodat een gelekte database geen gelekte wachtwoordlijst is. De Toolz bcrypt generator hashes elk wachtwoord met een instelbare kostenfactor (4 tot 31), verifieert een wachtwoord tegen een hash die u plakt, en toont de versie, de kosten en het zout dat het heeft geparseerd Het produceert de standaard $2b$ formaat dat OpenBSD, PHP password_hashbcrypt-bibliotheken met 'Laravel' en 'Node' accepteren allemaal en draaien volledig aan de clientzijde.

Wat is bcrypt?

Bcrypt is een functie voor het hashen van wachtwoorden, ontworpen door Niels Provo's en David Mazieres en gepresenteerd in hun USENIX-artikel uit 1999 "Een toekomstaanpasbaar wachtwoordschema". Het is gebouwd op het Blowfish blokcijfer, maar met een twist: in plaats van gegevens te versleutelen, wordt Blowfish' s sleutel-opstelling stap over en over uitgevoerd, met het wachtwoord en een willekeurige salt als het belangrijkste materiaal Het resultaat is een eenrichtingshash die goedkoop is om één keer te berekenen en duur om een miljard keer te berekenen, wat precies de opslagbehoeften van het wachtwoord van de eigenschap is.

Dat & quot; expres duur" idee is de kern ervan Een algemene hash als SHA-256 is zo ontworpen dat hij snel is, omdat controlesommen en integriteitscontroles snelheid willen Wachtwoord-hashing wil het tegenovergestelde Als een aanvaller je database steelt, is het enige wat er tussen staat en elk wachtwoord in platte tekst hoe lang het duurt om te raden Een snelle hash laat een moderne GPU miljarden kandidaten per seconde testen; een bcrypt-hash tegen een verstandige kostpetten die op een paar duizend per seconde per kern Hetzelfde gelekte bestand, enorm verschillende uitkomst.

Bcrypt heeft meer dan twee decennia overleefd omdat het de basisprincipes goed heeft en omdat het aanpasbaar is De kostenfactor betekent dat hetzelfde algoritme dat is afgestemd op de hardware van 1999 kan worden ingebeld voor de hardware van 2026 zonder iets anders te veranderen. Het blijft een aanbevolen optie in de OWASP Wachtwoord Opslag Cheat Sheet, en het is de out-of-the-box standaard in Laravel, Spring Security, en vele andere stacks waar ik in werk Als je de diepere achtergrond wilt over waarom snelle hashes verkeerd zijn voor deze baan, de online tools voor gegevensprivacy de gids behandelt de redenering die de hele industrie in de richting van langzame, gezouten hashing duwde.

Wat bevat een bcrypt hash?

Een van de leukste dingen aan bcrypt is dat de uitvoer zichzelf beschrijft Neem een echte hash:

$2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW

Lees van links naar rechts, splits op de dollartekens en het vertelt je alles wat nodig is om een wachtwoord ertegen te verifiëren:

veld	toonbeeld	veelbetekenend
vertaling	2b	De bcrypt variant. 2b is het huidige gecorrigeerde OpenBSD-formaat
prijs	12	De werkfactor De sleutelopstelling loopt 2^12 = 4096 iteraties
Salt	R9h/cIPz0gi.URNNX3kh2O	22 tekens aangepaste Base64, decoderen naar 16 willekeurige bytes
Digest	PST9/PgBkqquzi.Ss7KIUgO2t0jWMUW	31 tekens die de 23-byte bcrypt-uitvoer coderen

Omdat het zout en de kosten binnen de string leven, hoeft verificatie niets anders. Wanneer u een hash in de bcrypt generator verifieer de modus, het leest de kosten en het zout rechtstreeks uit de string, berekent de samenvatting opnieuw met precies dat zout en vergelijkt. Er is geen aparte zoutkolom om te beheren, wat een van de redenen is waarom bcrypt zo prettig is om op te slaan: het is één ondoorzichtig veld in uw gebruikerstabel.

Het aangepaste Base64 alfabet is een notitie waard, omdat het mensen naar boven laat struikelen Bcrypt gebruikt ./A-Za-z0-9, wat een andere volgorde is dan standaard Base64 Een bcrypt salt is geen standaard Base64 string, dus probeer het niet te decoderen met een generiek Base64 tool en verwacht betekenisvolle bytes Als je nieuwsgierig bent naar de standaard variant die overal elders wordt gebruikt, dan is de base64-codering gids loopt door het normale alfabet en waar het verschijnt.

Hoe genereer ik een bcrypt hash?

In de tool is het drie stappen: typ een wachtwoord, kies een kostprijs, klik op Genereren Onder de motorkap doet het genereren van een hash meer dan het eruit ziet Eerst wordt een cryptografisch sterk willekeurig zout van 16 bytes gemaakt met behulp van de Web Crypto API Dan voert bcrypt zijn dure sleutelschema uit, zaaiend met het wachtwoord en zout en itererend 2^cost keer Eindelijk codeert het een vaste magische string (& quot; OrpheanBeholderScryDoubt") 64 keer met de resulterende cijferstatus en Base64-codeert de output Die hele dans produceert de hash van 60 tekens.

De meest voorkomende verrassing is dat twee keer hetzelfde wachtwoord hashen twee verschillende hashes geeft Dat is correct en opzettelijk Elke hash krijgt zijn eigen willekeurige salt, dus twee gebruikers die allebei kiezen hunter2 eindig met compleet verschillende opgeslagen waarden Een aanvaller die de tabel steelt, kan niet zeggen dat twee accounts een wachtwoord delen, en kan een vooraf berekende tabel niet opnieuw gebruiken over accounts heen Als u een specifieke hash wilt reproduceren om te testen, levert u de volledige salt string in plaats van een kale kost, wat precies is wat de verificatiemodus intern doet.

In uw applicatiecode stelt u dit nooit met de hand samen U belt de bibliotheek

// PHP
$hash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]);

// Node with bcrypt / bcryptjs
const hash = await bcrypt.hash(password, 12)

// Laravel
use Illuminate\Support\Facades\Hash;
$hash = Hash::make($password); // bcrypt by default

De Toolz-tool is bedoeld voor de momenten rond die code: gezond verstand-checken hoe een hash eruit ziet tegen een bepaalde kostprijs, het genereren van een bekende hash voor een seeder of een test armatuur, of bevestigen dat een hash die je in een config hebt gevonden overeenkomt met het wachtwoord dat je denkt dat het doet.

Hoe kies ik een kostenfactor?

De kostenfactor is de enige knop waar je over moet nadenken, en het eerlijke antwoord is & quot; meten, niet kopiëren." De vuistregel van OWASP is dat een enkele hash ergens ongeveer een kwart seconde nodig heeft op je productiehardware Dat doel brengt twee tegengestelde krachten in evenwicht: te laag en je maakt kraken goedkoop, te hoog en elke legitieme login betaalt de prijs, wat belangrijk is als een druk eindpunt elk verzoek in de weg staat.

Omdat de kosten een macht van twee zijn, verdubbelt elke stap het werk Kosten 11 is twee keer zo langzaam als kosten 10, kosten 12 is vier keer zo langzaam Op typische serverhardware uit de jaren 2020 landen de kosten 10 tot 12 in de juiste buurt, daarom standaard raamwerken daar De tool toont een ruwe tijdschatting terwijl u de schuif sleept, zodat u kunt voelen hoe snel de kosten stijgen, maar behandel dat als een relatieve gids, niet als een benchmark van uw server. Het echte aantal hangt af van uw CPU, en de enige manier om het te weten is tijd password_hash op de doos die het zal draaien.

Eén praktisch patroon dat de moeite waard is om te weten: omdat de kosten in elke hash zijn opgeslagen, kunt u deze in de loop van de tijd verhogen zonder migratie. Bij een succesvolle login heeft u de leesbare tekst even in de hand, dus u controleert of de opgeslagen hash's-kosten onder uw huidige doel liggen en, zo ja, opnieuw hashen en bijwerken PHP legt dit rechtstreeks bloot via password_needs_rehash. Het betekent dat uw beveiliging gelijke tred houdt met hardware zonder ooit een wachtwoordreset te forceren.

Bcrypt versus SHA-256, Argon2 en scrypt

De vergelijking die het belangrijkst is, is bcrypt tegen een gewone snelle hash, en tegen de nieuwere geheugenharde functies. Hier leest u hoe ze in de rij staan voor wachtwoordopslag:

Functie	Gezouten	Vertraag met opzet	Geheugenhard	Goed voor wachtwoorden?
MD5/SJA-256	Nee (op zichzelf)	heel weinig	heel weinig	Nee, veel te snel
bcrypt	Ja, ingebouwd	Ja, afstembare kosten	heel weinig	Ja, aanbevolen
scrypt	ja	ja	ja	ja
Argon2id	ja	ja	ja	Ja, bij voorkeur voor nieuwe systemen

Een kale SHA-256 van een wachtwoord, zelfs gezouten, is het verkeerde hulpmiddel: het is ontworpen voor snelheid, dus een gelekte database van gezouten SHA-256-hashes valt snel naar een GPU. Als je alleen een snelle samenvatting nodig hebt voor een controlesom of een cachesleutel in plaats van een wachtwoord, dan is dat wat de hash generator is voor, en het onderscheid is het hele punt Argon2id, de winnaar van de 2015 Password Hashing Competition, voegt geheugenhardheid toe, die bestand is tegen de aangepaste hardware die bcrypt kan versnellen, en het is de eerste keuze voor een gloednieuw systeem waarbij je de runtime controleert Maar bcrypt is niet verouderd Het is beproefd, het is de standaard in tools die ik dagelijks gebruik, en het kiezen ervan is een goede beslissing, vooral wanneer uw framework het verzendt De fout die u moet vermijden is niet & quot;bcrypt in plaats van Argon2, & quot; het is & quot; een snelle hash in plaats van een van hen." Voor een bredere tour heeft de nutsvoorzieningen Productiviteitstools voor ontwikkelaar gids heeft de kaart.

Hoe zit het met de limiet van 72 bytes en andere gotcha's?

Bcrypt leest alleen de eerste 72 bytes van het wachtwoord Alles wat voorbij is dat stil wordt genegeerd, wat voor normale wachtwoorden er nooit toe doet, maar wel een zeer lange wachtwoordzin kan bijten, vooral een met UTF-8-tekens van meerdere bytes waarbij het aantal bytes sneller stijgt dan het aantal tekens De tool waarschuwt u wanneer uw invoer 72 UTF-8 bytes overschrijdt, zodat de afknotting nooit een stille verrassing is. Sommige systemen werken rond de limiet door het wachtwoord vooraf te hashen met SHA-256- en Base64-codering voordat het wordt overhandigd aan bcrypt, waardoor een willekeurig lang wachtwoord in een vaste korte invoer wordt gevouwen; als u dit doet, log het dan consistent in.

De andere gotcha is het versievoorvoegsel Je zult zien $2a$, $2y$, en $2b$ in het wild. $2a$ was het origineel, $2y$ werd een PHP-specifieke tag geïntroduceerd nadat in sommige implementaties een bug voor tekenuitbreiding was gevonden, en $2b$ is de huidige gecorrigeerde OpenBSD versie Voor nieuwe hashes die u wilt $2b$, wat deze tool produceert Alle drie verifiëren ze identiek voor gewone ASCII-wachtwoorden; de verschillen komen alleen naar boven met bepaalde niet-ASCII-bytes nabij de grens van 72 bytes. Wanneer u een token plakt in een tool die ook gestructureerde inloggegevens inspecteert, zoals de JWT decoderHoud er rekening mee dat een bcrypt-hash geen token is dat u decodeert om een payload te lezen; het is een eenrichtingsoverzicht dat niets te onthullen heeft.

Waar de bcrypt generator in een echte workflow past

Op zichzelf is een hash slechts de helft van het verhaal, dus de mixer zit naast de andere inloghulpmiddelen die ik openhoud. Wanneer ik een testdatabase aan het seeden ben of een demo-account aan het opzetten ben, genereer ik het wachtwoord zelf met de wachtwoordgenerator, controleer of het een verstandige sterktebalk verwijdert met de controle van de wachtwoordsterkte, en voer het dan pas door de bcrypt generator om de opgeslagen hash te krijgen Die volgorde doet er toe: een sterk willekeurig wachtwoord achter een cost-12 bcrypt hash is echt moeilijk te kraken, terwijl een zwak wachtwoord achter dezelfde hash nog steeds valt voor een woordenboekaanval, omdat de aanvaller alleen maar het handjevol waarschijnlijke kandidaten hoeft te raden in plaats van de hele sleutelruimte De kostenfactor kost je tijd; de wachtwoordentropie is waar die tijd aan wordt besteed.

De verificatiemodus verdient zijn plaats tijdens het debuggen Wanneer een login op mysterieuze wijze mislukt in de enscenering, is de snelste manier om het probleem te isoleren het plakken van de opgeslagen hash en het wachtwoord waarvan u denkt dat het correct is en kijken of ze overeenkomen Een match betekent dat de bug stroomopwaarts is, in hoe het wachtwoord de cheque bereikt; een mismatch betekent dat de opgeslagen hash is geschreven met een ander wachtwoord of een verminkte codering. Beide antwoorden besparen u op gissen, en omdat het geheel lokaal draait, kunt u het doen met een echte hash uit een database zonder dat die hash ooit uw machine heeft verlaten. Het is hetzelfde principe aan de clientzijde achter elk hulpmiddel op de site, en voor het aanraken van inloggegevens is het niet leuk.

Veelgestelde vragen

Is het veilig om een echt wachtwoord te hashen in deze bcrypt generator?

Ja, omdat het hashen volledig in uw browser gebeurt en er nergens iets naartoe wordt verzonden U kunt dit bevestigen in het tabblad Netwerk van uw ontwikkelaarstools: het genereren van een hash doet geen verzoek Dat gezegd hebbende, een browsertabblad is geen wachtwoordbeheerder, dus vermijd het plakken van de live-referenties van een productieaccount op een webpagina die u niet hebt gebouwd, en sluit het tabblad wanneer u klaar bent.

Waarom produceert hetzelfde wachtwoord elke keer een andere bcrypt-hash?

Omdat bcrypt voor elke hash een nieuwe random salt genereert en deze mengt in het resultaat Dit is een functie: twee gebruikers die hetzelfde wachtwoord kiezen krijgen nog steeds verschillende opgeslagen hashes, zodat een aanvaller geen gedeelde wachtwoorden kan spotten of een vooraf berekende tabel kan hergebruiken Verificatie werkt nog steeds omdat het zout in de hash-string zelf wordt opgeslagen.

Welke kostenfactor moet ik gebruiken voor bcrypt?

Gebruik de hoogste kosten die uw inlogstroom kan verdragen zonder een vervelende vertraging, die voor de meeste servers uit de jaren 2020 10 tot 12 kosten. OWASP suggereert dat een enkele hash ongeveer een kwart seconde op uw productiehardware moet duren. Omdat elke stap het werk verdubbelt, meet u op uw eigen server in plaats van een nummer te kopiëren, en verhoog de kosten om de paar jaar naarmate de hardware versnelt.

Kan een bcrypt-hash worden teruggedraaid naar het wachtwoord?

Nee Bcrypt is een eenrichtingsfunctie, dus er is geen wiskundige manier om een hash terug te zetten in het originele wachtwoord De enige aanval is gissen: een aanvaller hashes kandidaat wachtwoorden met hetzelfde zout en kosten en controles voor een match Daarom is de kostenfactor van belang, omdat het bepaalt hoe duur elke gok is, en waarom sterke unieke wachtwoorden plus een hoge kosten maken gissen onpraktisch.

Is bcrypt anno 2026 nog veilig, of moet ik overstappen naar Argon2?

Bcrypt wordt nog steeds als veilig beschouwd voor wachtwoordopslag en blijft een aanbevolen optie in het OWASP Wachtwoordopslag Cheat Sheet Argon2id, de winnaar van de Password Hashing Competition 2015, heeft de voorkeur voor nieuwe systemen waarbij u de runtime beheert omdat het ook bestand is tegen GPU- en gespecialiseerde hardware-aanvallen. Bcrypt is een goede keuze, vooral wanneer uw raamwerk het als standaard verzendt; de echte fout is het gebruik van een snelle hash voor algemene doeleinden in plaats van een functie voor het hashen van wachtwoorden.

Wat is de limiet van 72 bytes in bcrypt?

Bcrypt leest alleen de eerste 72 bytes van het UTF-8 gecodeerde wachtwoord, dus alle tekens daarbuiten worden genegeerd Voor normale wachtwoorden maakt dit nooit uit, maar een zeer lange wachtwoordzin kan worden afgekapt, daarom hashen sommige systemen het wachtwoord vooraf met SHA-256 vóór bcrypt Deze tool waarschuwt u wanneer uw invoer groter is dan 72 bytes, zodat de afknotting nooit een verrassing is.

Wat betekenen de voorvoegsels van $2a$, $2b$ en $2y$?

Het zijn versietags voor het bcrypt-uitvoerformaat. $2a$ was het origineel, $2y$ was een PHP-specifieke oplossing voor een bug voor tekenuitbreiding, en $2b$ is de huidige gecorrigeerde OpenBSD-versie Voor nieuwe hashes is $2b$ correct, wat deze tool oplevert Alle drie verifiëren ze identiek voor ASCII-wachtwoorden; de verschillen verschijnen alleen met bepaalde niet-ASCII-bytes op de grens van 72 bytes.

Is bcrypt hetzelfde als encryptie?

Nee Encryptie is omkeerbaar met een sleutel, dus versleutelde data kunnen weer gedecodeerd worden naar het origineel Bcrypt hashing is eenrichtingsverkeer en opzettelijk traag, en het is alleen bedoeld voor verificatie: je hoeft nooit het wachtwoord te herstellen, alleen om te bevestigen dat iemand de juiste heeft getypt Wachtwoorden opslaan met encryptie in plaats van hashen is een antipatroon, want wie de sleutel in handen heeft, kan elk wachtwoord herstellen.