We don't choose who we are, but we do choose who we become.
“明文密码”，顾名思义是传输或保存为明文的密码，翻译自英文的Cleartext Password。从信息安全的角度出发，任何网络服务都不应该保存或发送明文密码。但今天仍有很多网站，包括一些大家耳熟能详的收费服务，还留有这类一旦被攻击者入侵就会酿成灾难的安全隐患。
于是就有了Plain Text Offenders这个网站，专门收集那些“会给忘记密码的用户发送明文密码邮件”的博客——这代表着您的密码在服务器上并没有被哈希函数加密后才储存（一个理想的cryptographic hash function，所有hashing都应该是单向且不可逆的）。
目前看到的几大受影响服务——
In conclusion, the main thing we did wrong when designing ATM security systems in the early to mid-1980s was to worry about criminals being clever; we should rather have worried about our customers: the banks’ system designers, implementers, and testers, being stupid.
总结而言，我们在1980年代设计ATM安全系统的最大挫败在于我们过于担忧犯罪者的智慧；我们本应该担忧系统架构设计员，开发人员以及测试人员的愚蠢。
– Ross Anderson
Ross大叔的《Security Engineering》（第一版是公开的）可以说是所有系统/网络安全新生必读的教材了。假如开发人员都好好读这本吐槽各种安全技术的书，他们也不至于接连成为黑客的笑柄。顺便一提，此人是个DRM无用的提倡者，他的观点是，假如你有一个庞大的数据库，要么它会被人滥用，要么它没办法被使用——两者你只能选一。
有鉴于Proxy将成为贫苦大众（特指“没能力购买网络服务”的网民）今后数年的必备用品，Proxy 1.0的原始框架已无法承载这种压力。最近不少Proxy 2.0的设计蓝图浮出水面，本人亦有一些考量，这里简单小结一下。
关于SSL安全的文章已经写过三篇，但我始终没找到一个比较简单的判断方式。这里推荐一家叫做SSL Labs的组织，他们提供SSL安全测试，各位有兴趣可以拿自己常用的加密域名试试，该网站提供的入门信息也不错。
PS：假如你已经在攻击之中，那你浏览器看到的证书和SSL Labs服务器看到的证书很可能不同；所以不能把SSL Labs当成唯一标准。
另一方面，TLS Renegotiation的漏洞看来比预想情况要稍微严重一些。这是一个协议上漏洞，虽然不会造成直接的通信内容泄露，但可被利用来组合攻击（例如通过服务器的某些漏洞显示被攻击者的加密信息）。除了修改TLS协议外没有容易的解，目前完全禁止TLS Renegotiation（在服务器端）是最好的办法。
更新：如果文字解释太难理解，这里有一个漂亮的图解（PDF）
微软准备在周二修正从XP到7各个平台，估计其中至少有一个与近日SSL null-prefix证书泄露有关。这个Bug从被发表到今天已经存在于他们的Crypto API超过3个月，没有patch，没有提醒，没有报告——直到paypal现在来找微软，说“你给我赶快更新，伪造我们的证书都在网上乱窜了”的时候，微软才想着要动身了。不知道他们自己的顶级开发团队有何感想？
顺便一提，IE全系列，Chrome全系列，Safari for Win全系列都使用这个API。申请有null-prefix的证书也不是困难的事情。
关于SSL的事情我已经说的够多了：一个成功而隐蔽的null-prefix攻击需要混合CA疏忽（获取伪造证书或*.domain验证），OCSP妨碍（防止证书被撤销）与软件漏洞（利用null-prefix让软件接纳伪造证书）——它们都逃不过用户自己的警觉。
