我曾经接手了一个系统的开发，这个系统在全国有200个客户在使用，它有硬编码的密码。是的，代码实际上写着:

if password = "a"

去年，我离开了一家汽车ERP公司，该公司数百个客户的服务器上都有相同的管理密码。我猜我走后他们没有全部换掉。

我不知道这是不是最糟糕的，因为我见过一些非常糟糕的，但是:

几年前，我工作的地方引进了一个叫做FOCUS的系统。不知道它还在不在。它非常适合做报告，我们开发并教了大约一千两个非It人员如何生成他们自己的报告。非常方便。他们可以做基本的报告，一些人可以做中等难度的工作，IT可以帮助处理较难的工作。

所有用于报告的数据都被定期复制到FOCUS自己格式的影子数据库中。对于更敏感的数据，我们设置安全选项，加密数据。一切都很好。

So, one day my boss calls me in, and we've lost the password to one of the sensitive databases. It's going to be hard to reproduce the data in this case, so he asks me to see if I can break the security. I had no experience as a hacker, so it took me about 5 or 6 hours to hand him the password. I started by creating some test files, and encrypting them with different passwords. I found that changing one character in the password would change two bytes in the encrypted file, specifically, the high nybble of one byte, and the low nybble of another byte. Hmmmm, says I. Sure enough, they stored the password somewhere in the first 80 bytes of the encrypted, but obfuscated the password by splitting the bytes into nybbles, and storing them in predictable places.

不久之后，我们就编写了一个REXX脚本，该脚本在VM/CMS系统下运行，可以告诉我们任何加密数据库的密码。

那是很久以前的事了——在90年代初，我相信他们已经解决了这个问题。嗯，非常确定。

测试一些银行柜员软件后，我打电话给技术部安排了一次拨号IP会话。“您想连接到哪个系统，生产系统还是测试系统?”

真实的故事。

最近，我被要求对一家公司的网站进行代码审查，希望我的雇主把这个网站作为一个维护项目。

我没花多长时间就发现了网站根目录下的纯文本文件，其中包含大约6000个客户的信用卡详细信息，包括账单名称、地址和CVV代码。它的名字甚至都没有想象力!

这是该网站最糟糕的问题，但它也充满了SQL注入问题。

我们礼貌地指出了这些问题，网站所有者将其退回到原始开发人员那里寻求解释。

在登录时，有一个隐藏的字段，让“网站管理员”选择成功和失败时要包含的文件。

是的，/etc/password工作了。

或者在“log”目录中，有order-xxx。order-xxx.txt包含卡号，包括检查号和验证日期。

我记得申请大学的通用应用程序网站有这个“安全”功能，它宣布将在一定时间后注销你。但是，他们使用了一个警告框，如果你没有真正回应，就会暂停倒计时，使你的会话无限期。