Bcrypt-wachtwoordhashgenerator

Die vreemde tekenreeks lezen die je krijgt

Een bcrypt-hash ziet eruit als ruis, maar heeft een vaste anatomie die de moeite waard is om te kennen. Hij begint met een versiemarkering zoals $2a$ of $2b$, gevolgd door de kostfactor die je koos, dan tweeëntwintig tekens van de willekeurige salt, en tot slot de eenendertig tekens van de eigenlijke hash. Alles wat een verifiëerder nodig heeft, reist mee in die ene tekenreeks — daarom past het geheel in één enkele databasekolom, en daarom levert het genereren van een hash voor hetzelfde wachtwoord twee keer twee verschillende tekenreeksen op die allebei toch geldig zijn. De salt verschilt elke keer, dus de uitvoer verschilt elke keer; controleert je backend later een login, dan leest hij de salt terug uit de opgeslagen tekenreeks, hasht de poging ermee, en vergelijkt het resultaat.

Waar je deze pagina echt zou gebruiken

Meestal gebeurt bcrypt-hashing binnen je applicatie, niet in een browser — maar er zijn momenten waarop een handgemaakte hash precies is wat je nodig hebt. Een testdatabase vullen met accounts waarvan je de wachtwoorden kent. Een vergrendeld beheerdersaccount redden door een verse hash rechtstreeks in de gebruikerstabel te schrijven. Checken welke vorm van tekenreeks een library produceert voordat je de kolom ervoor dimensioneert. In al deze gevallen plak je een wachtwoord, kopieer je de hash, en zet je hem waar je logincode er een verwacht. Eén ding dat je nooit moet doen: hashes als tekenreeksen vergelijken in je eigen code. Door de salt levert hetzelfde wachtwoord verschillende hashes op — verificatie moet via de compare-functie van je library, die weet hoe hij de salt eruit terug kan lezen.

Een kostfactor kiezen waar je mee kunt leven

Elke stap in de kostfactor verdubbelt het werk, voor jou en voor een aanvaller allebei. Acht is snel en kun je het best aan legacy-compatibiliteit overlaten; tien, hier de standaardwaarde, is de gangbare productiekeuze; twaalf koopt comfort als logins zeldzaam zijn; veertien duurt zelfs bij het genereren al enkele seconden. Een eerlijke waarschuwing over timing: deze pagina draait een pure JavaScript-implementatie, trager dan de native code op je server, dus behandel de vertraging die je hier voelt als een bovengrens, niet als een benchmark — meet op de machine die de logins écht gaat verwerken. En omdat een hash maar zo goed is als wat erin gaat, levert de wachtwoordgenerator een sterke invoer, terwijl alles wat geen wachtwoord is — bestanden, documenten, platte tekst — juist bij de SHA-hashgenerator hoort.

Waarom bcrypt in plaats van een gewone hash

Een gewone SHA-hash van een wachtwoord is op moderne hardware snel te kraken met brute force. Bcrypt is bewust traag — de kostfactor bepaalt precies hoe traag — en salt automatisch, zodat hetzelfde wachtwoord nooit twee keer dezelfde opgeslagen hash oplevert. Daarom is het nog steeds een standaardkeuze om wachtwoorden server-side op te slaan.