一个密码在树莓派上要花多少

这里的统计页面可以加密码保护。给这个密码算哈希，是本服务里唯一一个应该慢的操作——正是它让一份被偷走的哈希变得难以攻破。问题只是：在这台硬件上，慢到什么程度。

在运行本站的那台机器上实测，PHP 8.4.21，aarch64：

bcrypt 的成本参数是一个指数：每上一级，工作量翻一倍。测出来的正是这个翻倍，这是个好迹象，说明没有别的东西在干扰。

为什么默认值在这里是错的选择

PHP 把 bcrypt 的默认成本从 10 提到了 12。在机房里的服务器上这是合理的提升——几十毫秒而已。在一块小小的 ARM 板子上，它是半秒多的纯 CPU 时间，而这台机器同时还在为所有其他人绘制计数器图片。

每次登录半秒钟，本身就已经糟糕。作为一份邀请，它更糟：登录入口谁都能调用，而每次调用都要吃掉服务整站的那一颗 CPU 的 560 毫秒。这样一来，密码校验就成了这里最便宜的一种压垮方式。

所以成本被钉死在 10，而不是交给默认值。这比 PHP 今天所选的确实更弱，而这话该明说，不该埋着：成本 10 的哈希，攻破代价是成本 12 的四分之一。抵回这一点的，是这个密码实际保护的东西——一页访问数字的可见性，不是账户，不是钱，不是身份。它背后没有任何可以被接管的东西。

PASSWORD_DEFAULT 按设计就是一个会移动的值。多年前写下的、用了它的代码，会随着每一次 PHP 升级悄悄变慢——同一份源码，同一份输入，好几倍的运行时间。这是预期行为，对大多数软件来说也是对的。

只有当机器扛不住时它才是错的，而机器扛不住时并没有任何东西会警告你。升级成功了，测试通过了，页面照样能用。它只是多花了半秒钟，而这个数字，不去动手测就没人会看。