密码破解测试

去年秋天，密码我在一个CTF竞赛里碰到一道密码题，破解加密后的测试字符串是“U2FsdGVkX1+...”，一眼认出是密码OpenSSL的AES加密特征。当时第一反应不是破解写脚本爆破，而是测试翻出三年前自己写的一个测试工具——那玩意儿本来只是用来验证弱口令字典的，结果那天派上了用场。密码这事让我意识到，破解密码破解测试这行当，测试工具和直觉缺一不可，密码但更关键的破解，是测试你得清楚自己到底在测什么。

很多人以为密码破解就是密码拿个字典跑hashcat，等着屏幕跳出明文。破解真干过的测试人知道，那只是最后一步。前面还有一堆脏活：确认加密算法、判断是否有salt、估算密钥空间、评估硬件算力。我见过一个新手，拿到一个bcrypt哈希直接上字典，跑了六个小时没结果，跑来问我是不是工具坏了。我让他先看看哈希前缀——$2a$12$，cost factor 12，单次验证就得几百毫秒，字典再大也扛不住。他后来换了策略，从社工信息入手，猜了三个候选密码，十分钟搞定。这行就是这样，蛮力有时候是最蠢的路。

说到具体案例，上个月帮朋友查一个老路由器的后台密码。管理员账户锁了，但telnet端口还开着。我连上去，发现固件是2013年的，登录逻辑里有个经典漏洞：密码比较用的是strcmp，但没限制输入长度。我写了个脚本，每次发一个字符，根据返回延迟判断是否匹配。听起来很玄，实际上因为网络抖动，前两百次全是噪声。后来我改成在本地串口上跑，延迟稳定在微秒级，半小时就还原出了八位密码。这方法教科书上叫“时序攻击”，但真用起来，环境比理论重要十倍。

工具方面，Hashcat和John the Ripper是标配，但别迷信它们。我电脑里常年备着几个自己写的Python小脚本，专门处理那些“非标准”情况——比如某个老系统用MD5但只取前16位，或者密码里混了不可打印字符。这些脚本代码不超过五十行，但比任何商业工具都顺手。有一次测试一个内部系统，密码策略要求包含一个emoji，Hashcat的默认字符集直接跪了。我手动构造了一个包含常见emoji的掩码，十分钟出结果。工具是死的，人是活的。

还有个坑得提：法律边界。我所有测试都在授权范围内，要么是自己的设备，要么是客户签了字的靶场。去年有个同行，帮人“测试”一个网站，结果对方其实是竞争对手，最后吃了官司。这行技术再牛，踩了红线就全完。我自己的规矩很简单：没有书面授权，连自己的路由器都不碰——万一ISP的条款里写了禁止未授权测试呢？

最后说个观察。现在很多系统用上了速率限制和账户锁定，纯在线爆破基本没戏。但离线破解反而更容易了，因为GPU越来越便宜。一张二手RTX 3090，跑NTLM哈希能到每秒几百亿次。这意味着什么？意味着如果你的密码是八个纯小写字母，哪怕加salt，也撑不过一天。所以我现在给朋友的建议就一条：密码长度比复杂度重要，十六个字符的短语，比八个字符的乱码安全得多。至于那些还在用生日当密码的，我只能说，祝你好运。