Bcrypt-generator og -kontrol

Sådan hasher du en adgangskode med bcrypt

1. Under Hash en adgangskode skriver du Adgangskode. En tæller viser længden i UTF-8-bytes og advarer dig, når den overstiger 72 bytes.
2. Vælg Omkostningsfaktor (4–14). Linjen under viser antallet af runder, for eksempel 10 → 2^10 = 1.024 runder.
3. Klik på Generér hash. En statuslinje følger arbejdet, og siden kan stadig bruges, mens det kører. Når det er færdigt, viser værktøjet tiden og Bcrypt-hash, klar til at blive kopieret.
4. Hashen er delt op i sine dele: Version, Omkostning, Salt (22 tegn) og Hash (31 tegn).

For at kontrollere en adgangskode mod en hash skriver du adgangskoden, indsætter hashen (den, du lige har lavet, er udfyldt automatisk) og klikker på Kontrollér adgangskode. Resultatet fortæller, om de passer sammen. Sæt kryds ved Skjul adgangskoder for at skjule begge adgangskodefelter.

Hashingen kører i din browser med biblioteket bcryptjs, som først indlæses, når du har brug for det. Ingen adgangskode og ingen hash sendes nogen steder hen.

Sådan virker bcrypt

bcrypt (Provos og Mazières, 1999) er en hashfunktion til adgangskoder bygget på Blowfish-chifferet. I modsætning til SHA-256 er den bevidst langsom, og langsomheden kan justeres: Omkostningsfaktoren er en toerpotens, så hvert +1 fordobler arbejdet. En omkostning på 10 betyder 1.024 gentagelser af den dyre nøgleopsætning, og en omkostning på 12 betyder 4.096. Den langsomhed betyder næsten intet, når en bruger logger ind, men den gør det langt dyrere at brute-force en stjålet database.

En hash som $2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy læses sådan:

• $2b$: versionen. $2a$ og $2y$ (PHP) er kompatible og kan kontrolleres her. $2x$ markerer hashes fra en gammel implementering med fejl og afvises.
• 10: omkostningsfaktoren.
• De næste 22 tegn: et tilfældigt salt på 128 bit i bcrypts eget Base64-alfabet (./A-Za-z0-9).
• De sidste 31 tegn: resultatet på 184 bit.

Fordi saltet er tilfældigt og gemmes i hashen, giver hashing af den samme adgangskode to gange to forskellige hashes, og begge kan bekræftes korrekt. Det er også grunden til, at man kontrollerer en adgangskode med en verificeringsfunktion i stedet for at sammenligne hashes.

Valg af omkostning

Vælg den højeste omkostning, din server kan klare, uden at logins bliver langsomme, typisk omkring et kvart sekund pr. hash. OWASP anbefaler en omkostning på mindst 10 til bcrypt. Browsere kører bcrypt i JavaScript, som er flere gange langsommere end en nativ serverimplementering: Fra en omkostning på 12 advarer værktøjet om, at hashing kan tage et til flere sekunder, og hvert ekstra trin fordobler tiden. Arbejdet er delt i korte stykker, så siden ikke fryser.

Til nye systemer foretrækker OWASP nu Argon2id, mens bcrypt stadig er acceptabel, hvor Argon2id ikke findes.

Grænsen på 72 bytes

bcrypt bruger kun de første 72 bytes af adgangskoden. Alt efter det ignoreres uden besked. Bytes er ikke tegn: Et bogstav med accent fylder 2 bytes i UTF-8, og en emoji fylder 4. Det gælder også æ, ø og å. To lange adgangskoder, der har de første 72 bytes til fælles, giver den samme hash. Bytetælleren advarer dig, når en adgangskode er for lang. Nogle systemer forhasher lange adgangskoder (for eksempel med HMAC-SHA256 og derefter Base64) før bcrypt. Gør du det, må du aldrig give rå binære digests videre, fordi en nulbyte i mange implementeringer afslutter adgangskoden for tidligt.