Ce que coûte un mot de passe sur un Raspberry Pi

Les pages de statistiques peuvent être protégées ici par un mot de passe. Hacher ce mot de passe est la seule opération de ce service qui doit être lente — c'est ce qui rend coûteuse l'attaque d'une empreinte volée. La question est : à quel point, sur ce matériel.

Mesuré sur la machine qui fait tourner ce site, PHP 8.4.21 sur aarch64 :

PASSWORD_DEFAULT	560 ms	(donne cost 12)
cost 12	595 ms
cost 11	277 ms
cost 10	138 ms

Le paramètre de coût de bcrypt est un exposant : chaque pas double le travail. Les mesures montrent exactement ce doublement, ce qui est bon signe : rien d'autre ne vient interférer.

Pourquoi la valeur par défaut est ici le mauvais choix

PHP a relevé le coût par défaut de bcrypt de 10 à 12. Sur un serveur de centre de données, c'est une hausse raisonnable — quelques dizaines de millisecondes. Sur une petite carte ARM, ce sont plus d'une demi-seconde de calcul pur, sur une machine qui dessine en même temps les images de compteur de tous les autres.

Une demi-seconde par connexion est déjà mauvaise en soi. Elle est pire comme invitation : le point d'entrée peut être appelé par n'importe qui, et chaque appel consomme 560 ms du seul processeur qui sert tout le site. Cela fait de la vérification du mot de passe le moyen de saturation le moins cher qui existe ici.

Le coût est donc fixé à 10 plutôt que laissé à la valeur par défaut. C'est délibérément plus faible que ce que PHP choisit aujourd'hui, et cela mérite d'être dit franchement plutôt qu'enterré : une empreinte de coût 10 est quatre fois moins chère à attaquer qu'une de coût 12. Ce qui rachète cela, c'est ce que le mot de passe protège réellement — la visibilité d'une page de chiffres de visites, pas un compte, pas de l'argent, pas une identité. Il n'y a rien derrière à s'approprier.

La partie qu'on rate facilement

PASSWORD_DEFAULT est par conception une valeur mouvante. Du code écrit il y a des années qui l'utilise deviendra silencieusement plus lent à chaque mise à jour de PHP — même source, même entrée, plusieurs fois le temps d'exécution. C'est le comportement prévu, et pour la plupart des logiciels c'est le bon.

Ce n'est mauvais que lorsque la machine ne peut pas l'absorber, et rien n'avertit quand elle ne le peut pas. La mise à jour réussit, les tests passent, la page fonctionne toujours. Elle prend simplement une demi-seconde de plus, et personne ne regarde ce nombre s'il ne va pas le mesurer.