我最后工作的公司的FTP用户名和密码与他们的域名相同。他们不太在意反复警告。

不用说，网站没过多久就倒闭了。没有在线备份，所以他们不得不重建整个系统。但这并没有结束。这次事件后的新安全密码是一样的…加上123。

我们工作时的手机。

你必须用你的4位ID登录，然后按#，然后输入你的4位密码和#。但如果你不输入任何密码并按#，它就会让你登录。

Failphone失败。

我的目标是我曾经的客户。我无法登录，所以我打了客服电话。他们只问了我的用户名，没有问任何安全问题，也没有试图验证我的身份。然后，他们没有将密码重置发送到他们存档的电子邮件地址，而是问我该发送到哪个电子邮件地址。我给了他们一个不同于我文件上的地址，并重新设置了密码。

所以本质上，黑客只需要我的用户名，他就可以访问我的账户。这是一家至少90%的美国人都听说过的大银行。这件事发生在大约两年前。我不知道这是一个缺乏训练的客户服务代表还是这是标准程序。

当关键IT员工离开公司时，不更改管理密码。

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

几年前，我工作的地方引进了一个叫做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年代初，我相信他们已经解决了这个问题。嗯，非常确定。

一个在线文档管理器怎么样，它允许设置你能记住的所有安全权限……

直到你进入下载页面……download.aspx吗?documentId = 12345

是的，documentId是数据库ID(自动递增)，您可以循环每个数字，任何人都可以获得所有公司文档。

当这个问题被提醒时，项目经理的回答是:好的，谢谢。但之前没有人注意到这一点，所以就让它保持现状吧。