bcrypt-generator

bcrypt är fortfarande ett av de säkraste valen för att lagra lösenord. Det är avsiktligt långsamt, härleder sitt eget salt och skalar mot bättre hårdvara genom en justerbar kostnadsparameter. Den här generatorn skapar en standardkompatibel bcrypt-hash från ett klartextlösenord så att du kan seeda en testanvändare, migrera ett konto mellan system eller jämföra värden mot en befintlig hash lagrad i en users.password-kolumn.

Så hashar du ett lösenord med bcrypt

  1. 1

    Ange klartextlösenordet

    Upp till 72 bytes — bcrypt trunkerar tyst allt därutöver.

  2. 2

    Välj en kostnadsfaktor

    10 är nuvarande standard; 12 är vanligt för nya system; 14 är paranoidt. Varje +1 fördubblar ungefär hashtiden.

  3. 3

    Ett slumpmässigt salt genereras

    16 bytes salt hämtas från en kryptografisk RNG och bäddas in i den resulterande hashsträngen.

  4. 4

    Kopiera hashen

    Utdata är en självbeskrivande sträng som `$2b$12$...` som innehåller version, kostnad, salt och digest.

Anatomi för en 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)

Hela strängen är 60 tecken. Kolumner av typen VARCHAR(60) eller CHAR(60) är standardschemat.

Rekommendationer för kostnadsfaktor

Kostnad Ungefärlig tid per hash (2024-CPU) Användningsfall
10 ~80 ms Äldre standard, fortfarande acceptabelt
12 ~300 ms Aktuell rekommenderad basnivå
13 ~600 ms Appar med högre säkerhetskrav
14 ~1.2 s Paranoidt; märkbar inloggningsfördröjning

Varje ökning fördubblar arbetsfaktorn. Om inloggningslatens under 500 ms är kritisk, håll dig till 10-12.

Versionsbyte: 2a vs 2b vs 2y

  • $2a$ — Ursprunglig specifikation från 1999. De flesta bibliotek skapar 2a-hashar.
  • $2b$ — Revision från 2014 som rättar en trunkeringsbugg i crypt_blowfish. Föredras för nya hashar.
  • $2y$ — PHP-specifik tagg, funktionellt likvärdig med $2b$.

Alla tre verifierar mot varandra; bara taggen i hashsträngen skiljer sig.

Vad bcrypt skyddar mot

  • Rainbow tables — Unikt salt per hash stoppar förberäknade uppslag.
  • GPU-/ASIC-knäckning — Blowfish key schedule är minnesbunden och ogästvänlig för GPU:er. Inte lika GPU-ogästvänlig som Argon2, men fortfarande långsam att brute force:a.
  • Databasläckor — Klartexten kan aldrig återställas från hashen utan brute force.

Vad bcrypt INTE skyddar mot: svaga lösenord (använd minimilängd och kontrollera mot läcklistor), credential stuffing (använd en andra faktor), phishing.

72-bytegränsen

bcrypt använder bara de första 72 bytesen av lösenordet. Längre indata trunkeras tyst, vilket är samma anledning till att många bibliotek nu rekommenderar att lösenordet förhashas med SHA-256 innan det matas till bcrypt. Moderna alternativ (Argon2, scrypt) har ingen sådan gräns.

Vanliga frågor

Ja för lösenordslagring, vid kostnad ≥ 12. OWASP listar det fortfarande som en acceptabel algoritm. Argon2id är det föredragna valet för nya system, men migrering av äldre bcrypt-hashar är normalt lågprioriterat.

För att saltet genereras slumpmässigt per hash. Verifiering tar saltet från den lagrade hashen, hashar om det inskickade lösenordet med det och jämför.

De flesta bibliotek exponerar inte detta, och av goda skäl — förutsägbara salt motverkar hela poängen. Använd saltet som biblioteket genererar; det är den säkra vägen.

Ja — arbetsfaktorn är symmetrisk. Att verifiera en kostnad-14-hash tar 16x längre än att verifiera en kostnad-10-hash. Stäm av mot din inloggningskapacitet.

Relaterade verktyg