PHP 项目的用户密码设计

PHP 项目的用户密码设计
Photo by Towfiqu barbhuiya / Unsplash

简单聊一聊用户系统的密码存储设计。

历史变迁

首先,最开始大家用的都是明文存储用户的密码,想着,反正存储在服务端,也只有服务端看得到,

但这些年这么多脱裤事件,终于意识到不能再使用明文了,

于是,大家改用 md5 等哈希算法,为用户密码“加密”,但数据库泄漏后,仍然可以使用 字典攻击 破解。字典攻击 是用一个字典文件,储存了单词、短语、常用密码和他们 hash 后结果。将密码与 hash 结果对比,就能破解。

为了解决这个问题,研发工程师又在密码的hash的过程中加 salt, salt是一串随机值,与 hash 后的密码一起保存在数据库。  这恐怕只能使用暴力破解了,但现在GPU的发展,使得暴力破解成为可能,如果被脱裤,则更容易破解。

同时期的 GPU 的计算单元比CPU多, L1/L2/L3缓存和控制器较少, 所以GPU非常适合做并行且无需内存参与的计算任务。

解决方案

PHP 5.5 开始, 针对于 password, 给出了轻便的解决方案:password_hash(加密)、 password_verify(验证校验)、 password_need_rehash(判断是否需要重新加密);

这一套password解决方案,首先是把 salt 值体现到了 hash 值里面,这样就不需要在维护一个 salt 字段,再者支持了 BCRYPT, ARGON 算法。

BCRYPT 这个算法,相比md5 是一个慢速hash,比较消耗cpu, md5 毫秒级别, bcrypt  0.1 秒级别 ;我们一直想让代码运行的快点再快点,而加密算法反其道而行。

针对这个算法, 并且可以设置 cost,来调整耗时,假设后续机器性能大提升,也可以修改 cost;

上文也提到了,GPU等硬件升级会导致破解速度的加快。

第二种算法,在2015年密码hash竞赛中诞生,并且拿了冠军, 那就是 argon2, 这种算法使用大量内存和大量计算资源进行 Hash 计算, 内存和GPU的数据传输是很慢的(不展开讲),  可能就是 0.2 s 的级别。可以设置 memory_costtime_cost **两种 cost 来调整运算的耗时。

扩展

argon 有3个分支,详细可以线下去了解: PHP 版本 7.2+

  • Argon2d:更快,使用 data-dependent 的内存访问方式,data 是需要 Hash 的 password 和 salt。适合加密货币和不会收到 side-channel timing 攻击的应用。
  • Argon2i:使用 data-independent 的内存访问方式,更适合密码哈希等。他比 Argon2d 慢,因为它需要更多次内存计算(passes)来保护免受 tradeoff 的攻击。
  • Argon2id:是 Argon2i 和 Argon2d 的混合版本,第一次计算用 Argon2i,后续的计算用 Argon2d。如果没有特定的理由,推荐使用 Argon2id。

Argon 需要 安装 sodium 扩展

Read more

代码 Refactoring

重构不必谈之色变。 它也不是洪水猛兽,而是开发过程中持续进行的优化过程。让我们开始学习这个主题,重新认识它的价值。 🌟整洁代码 重构的主要目的是消除技术债务。它将混乱变成整洁的代码和简单的设计。 * 对于其他程序员来说,整洁的代码是显而易见的。 我并不是在谈论超级复杂的算法。糟糕的变量命名、臃肿的类和方法、魔法数字 - 等等,所有这些都会让代码变得混乱和难以理解。 * 整洁的代码不包含重复。 每次你需要对重复的代码进行更改时,你都必须记住对每个实例进行相同的更改。这会增加认知负担并减慢进度。 * 整洁的代码包含最少数量的类和其他活动部件。 代码越少,脑子里需要记住的东西就越少。代码越少,维护工作就越少。代码越少,错误就越少。代码就是责任,保持代码简短。 * 整洁的代码通过所有测试。 如果只有 95% 的测试通过,你就知道代码不整洁。如果测试覆盖率为 0%,你就知道你完蛋了。 * 整洁的代码维护成本低! 🗑️技术债(What) 每个人都尽最大努力从头开始编写出色的代码。可能没有程序员会故意编写不干净的代码,从而损害项目。但是干净的代码在什么时

By brian

CSV 格式说明和应用

问题 我们常常将多个字符串item使用逗号拼接成一个字符串,用来表示数组,使用时再用逗号切割成为数组。比如安卓机型列表: ALN-AL10,ALN-AL10,BRA-AL00,ALN-AL00/ALN-AL80 直到有一天,苹果设备也要用到这个机型列表,而它的每个机型都带着逗号,那我们使用逗号切割就得到了错误的数据。 iPhone15: iPhone15,4 iPhone15Plus: iPhone15,5 iPhone15Pro: iPhone16,1 iPhone15Pro_Max: iPhone16,2 为了解决这个问题,首先想到了换一个分隔符,比如 | ,再比如用一些不可见字符 : 0x01。 但我们不能保证这些字符串 item 一定不包含这些特殊字符,也许还有更好的方法。 既然是逗号分隔,首先想到的就是 CSV格式,毕竟 CSV 的全称就是Comma-Separated Values逗号分隔值。它是如何解决这个问题的? CSV格式 CSV 的RFC说明文档:https://datatracker.ietf.

By brian
开启了http2,但是http2_max_field_size 还在用默认值吗?

开启了http2,但是http2_max_field_size 还在用默认值吗?

排查1个异常接口,学到一个降本和接口提速的新思路。另外找到1个charles的"bug" 现象 测试同学反馈在iOS13设备上请求接口报错,将请求复制为 curl 命令。分别导入 apifox 和 在终端执行: * 在 apifox 请求正常 ✅ * 在终端请求失败 ❌ curl: (56) Failure when receiving data from the peer 测试同学又反馈另一个手机支持请求接口返回正常。 定位 有了正常和错误的请求curl,那直接对比二者差异就很简单了。对比发现,在终端执行失败的请求中多了一个较大的Cookie: app_token。按历史经验基本能确定是因为 Cookie 这个 header 条目太大,超过服务器的限制。 找云平台确定相关配置: ELB http1: header头限制 128KB,body 限制一个10G http2:

By brian
沪ICP备2022013452号-1