In the 1970's Stanford had IBM 2741 hardcopy terminals spread around campus networked to an IBM 360/67. Account passwords were three characters. During logon, the password prompt would overprint a three-position blob of about nine random uppercase characters, so the subsequently-typed password would supposedly be masked by the blob. However, everyone typed their passwords in lowercase, which were trivial to discern against the uppercase background blob. That meant you could usually walk up to any terminal, peruse the hardcopy typically left behind by the previous user, and easily logon with their account and password.

在我工作的一个网站上，他们使用用户名和密码作为组合主键。用户名自动是您的姓，不需要唯一。

这就只剩下一件独一无二的事情了…

在一些Unix机器(当然是所有的SunOS)上，您可以将setuid shell脚本链接到一个名为“-i”的文件。 shell脚本将文件名解释为它的第一个参数，并运行"sh -i" =一个交互式shell，并获得setuid文件所有者的许可。

因为大多数setuid shell脚本都是以根用户身份运行的，以便允许您执行一些需要根用户权限的操作，比如弹出CD或加载磁带。这意味着在20世纪90年代，在大多数大学的Unix机器上获得管理是很简单的。

有一次我有……创造性的差异……在我帮助建立的一个社区网站上，另一个编码器添加了一个新的PHP文件，该文件列出了审批队列中的文件，该文件还具有删除每个文件的链接。

不幸的是，这个脚本使用了整个通过模糊实现安全的概念。

不知何故，一个网络爬虫发现了这个页面，并跟踪了所有的删除链接。

不用说，修改元数据或删除文件的脚本现在需要登录。

附注:我与此无关，甚至不知道这个脚本的存在，直到当时的一位工作人员告诉我发生了什么。实际上，我现在又在为这个网站工作了，部分原因是为了确保这样的事情不会再发生。

我认为超级用户访问的空白用户名/密码字段是迄今为止最糟糕的。但我亲眼看到的是

if (password.equals(requestpassword) || username.equals(requestusername))
{
    login = true;
}

太糟糕了，一个操作员就有这么大的不同。

作为对所有读者的提醒，无论是否知情:我刚刚从一个专业那里买了一本800页的2008年版权的关于这个主题的书——在序言中，作者做了一个“嘿，等一下……”，在序言中详细指出，不止一个拥有丰富证书和现场经验的安全专业人士，嗯哼，被赋予了意义，……因为他们看到了一些看起来相对新手的入侵。

如果把它当作看似无害的，那么由于未经授权的活动，就会引发正式诉讼。作为一个专业人士，他们中的一些人被毁了。

我注意到的最后一次入侵涉及一家主要的银行服务，该服务已经存在了很长时间，以至于市民很少听到他们的品牌名称。整个商店的所有数据都是未加密的——但是，对于不知情的人来说，奇怪的是，这家银行实体已经成为了一个“清算所”(我不知道统计数据，但它超过了一半)，为不止一个零售品牌的信贷提供商处理信用卡交易。

入侵者只是在空投处放置了一个(装置)。(这是电信公司从世界各地进入的线路)没有花哨或复杂的交通监控工具，只有基本的。我建议每个人都监控今年2月以来的所有信用活动:所获得的是与当前活跃和有效信用账户上的有效名称相匹配的有效cc#。

空前的。

像往常一样，它是一个没有安全专业知识的人从管理权威的位置上运行一个商店。工程术语是“失效模式分析”……