开发者回忆学生时代做PHP登录功能时忽视安全加密的经历

这篇文章讲的是大约半年前那篇《让微软纸牌收费的诉讼》之后，某门课上发生的故事。

课程布置了一个用PHP制作Web系统的作业，我心想正好可以充分发挥PHP作为数据库集成利器的特性，于是得出的结论是：「做一个迷你版pixiv吧。」

关于语言和数据库（DB）的技术资料在网上到处都能找到，所以像下面这些功能：

多重标签与标签搜索功能

做起来都轻而易举，简单到让人觉得扫兴。

然而，在制作关键的「登录功能」时，却出现了一个大问题。

我对安全加密的知识为零，陷入了在网上搜索也完全找不到想要的信息的状况。

「GET会把信息放在URL里，所以要用POST」

「HTTPS会加密（SSL）通信，所以要通过HTTPS发送」

到这里为止，我踩中的都是连专业人士都要汗颜的完全正确的答案。

「等一下……不管怎么说都是HTTPS，万一通信内容以某种方式泄露了不就完了吗？密码不做哈希不是很危险吗？」

于是，我拼命思考「如何把密码哈希后发送到下一个画面」，最终得出的方案是——

「把密码哈希后用POST发送，同时把解开哈希值的密钥（也就是哈希值本身）一起发送过去，在下一个画面里解开」

我竟然装上了这么一个逻辑莫名其妙、如同迷宫一般的功能。

假设通信正在泄露，那么在你把哈希值一起发送出去的那一刻，哈希值也完全暴露在视野中了。作为加密，这连一毫米的意义都没有。

然而当时，因为登录功能（以及联动的个人主页功能）暂且能靠这个跑起来，我便心满意足地想着「好！完美的安全！」。

明明选择了HTTPS和POST这两个正确答案作为安全对策，却在此基础上又实现了一个毫无意义、过度防御的功能——「把密码哈希后连哈希值也一起发送出去」——我大概是全世界唯一一个这么干的人吧（笑）。

不过，大体上既然能想到「带着密码发送的通信，大概还是加密比较好吧」，这看起来像是个极其愚蠢的错误，但实际上不相当于自己独立尝试实现了公钥与私钥理论吗（笑）？？

也就是说，虽然以失败告终，但如果这个世界上不存在Diffie和Hellman，那么世界的加密方式岂不是会变成「把密码和哈希值同时发送」这种完全无意义的理论了。

※ 顺便一提，这时候的数据也因为一个黑帽同学通过Wi-Fi把我的电脑搞崩而消失了。

（这份数据被清除的时候，我还是专门学校二年级的学生，所以）