bcrypt.

bcrypt est un schéma de hachage de mots de passe publié en 1999 par Niels Provos et David Mazières (article USENIX « A Future-Adaptable Password Scheme »), qui utilise une variante du key schedule de Blowfish (« EksBlowfish ») pour dériver un hachage de 192 bits à partir d'un mot de passe salé. La coûteuse phase d'initialisation de clé entrelace le sel et le mot de passe au moyen d'expansions de clé répétées, puis chiffre 64 fois la chaîne constante « OrpheanBeholderScryDoubt ». Son paramètre de coût — le log2 du nombre de rondes d'initialisation de clé — permet aux défenseurs d'augmenter le facteur de travail à mesure que le matériel s'améliore ; un coût de 12 signifie 2^12 = 4096 itérations.

Une particularité déterminante est la limite stricte de 72 octets en entrée de bcrypt : tout ce qui dépasse l'octet 72 est silencieusement tronqué. C'est ce qui a provoqué l'incident d'octobre 2024 de l'authentification déléguée AD/LDAP d'Okta, où Okta construisait une clé de cache en appliquant bcrypt à userId + username + password ; pour les utilisateurs dont le nom d'utilisateur comptait 52 caractères ou plus, le mot de passe tombait au-delà du seuil de 72 octets et était ignoré, permettant à une identification précédemment mise en cache de s'authentifier. La leçon : pré-hacher les entrées longues (par exemple SHA-256 puis Base64) avant bcrypt, ou utiliser une fonction sans cette limite.

L'empreinte mémoire faible et fixe de bcrypt le rend aussi plus faible que les conceptions à coût mémoire face au cassage par GPU/ASIC. Il reste acceptable avec un coût >= 12, mais OWASP recommande désormais Argon2id (ou scrypt) pour les nouveaux systèmes.

flowchart TD
  P[Password + 128-bit salt] --> T{Input > 72 bytes?}
  T -->|Yes| TR[Bytes 73+ silently truncated]
  T -->|No| K
  TR --> K[EksBlowfish key setup]
  K --> C[Cost: repeat key schedule 2^cost times]
  C --> E["Encrypt 'OrpheanBeholderScryDoubt' x64"]
  E --> H["$2b$12$salt + 184-bit digest"]