@superwater 啊噢，我忽略了免翻墙。话说还是用个 Surge 、 Shadowrocket 之类的工具吧，手机翻墙很自在。

@dallaslu 啊噢，我忽略了免翻墙。话说还是用个 Surge 、 Shadowrocket 之类的工具吧，手机翻墙很自在。

g suite 可以开 exchange

315 要到了，百度害怕了？

曾经 StartCom Class 2 ，现在 Let's Encrypt 。

HashMap 和 HashTable 的区别……

想一想，如果大铁球的体积足够大，大到其密度小于空气，根本就不会落地了。

说说那两家 CA 的名字吧

这网站让人沉醉，还是先比一比谁能做出更好的软件杯官网吧

感谢楼主倾情分享。另，是不是该换个光头头像来应景？

LastPass 多年付费用户。

以后得 md5 和 sha-1 双检了，或者用 sha256 ……

@Immortal 丑得有下限……

MF843

参考一下 Twitter ，不仅 nickname 能改， username 也能改……

使用了 HTTPS ，那么被第三方攻击者嗅探到密码的风险，先不用过于费神考虑了， SSL 的中间人攻击稍后再说。值得关心的事情是「明文」提交给网站是否不妥。

1. 网站若被拖库，会暴露密码明文吗？

如果网站将密码明文入库，的确如此。

事实上，网站开发人员普遍有了不存储明文密码的意识。我们可以在安全链接的基础上明文传输密码，在服务端计算出 hash 后，与数据库中存储的 hash 值对比来验证密码是否一致。强制客户使用复杂密码，即使 hash 泄漏，也能对付得了暴力破解。

如果密码不够复杂，还是有可能被破解。预先准备一个庞大的密码字典，按指定算法获得的 hash ，做成一个映射表，使用 hash 反查即可立刻获得明文。所以有安全意识的开发人员会使用一段足够复杂的随机字符串，做为「盐」与密码明文连接后成一个新字符串，将计算出的 hash 值存储入库；同时盐也是明文存储的。 这样就能规避查表破解了。更严谨的做法是为每一个用户的密码都生成一个独一无二的「盐」。

除了用盐来得到口味不同的 hash 之外，还可以在「烹饪手法」上做文章，比如不断对 hash 加盐再算 hash 值，重复 N 次。

2. 传输加盐后的 hash ，会更安全吗？

比如我们在客户端实现 MD5 或 SHA256 这样的加密算法，如有必要还会重复 N 次；将处理后的内容发送给服务器，服务器拿去存储和验证。这样，网站可以明确的表示对客户的密码明文没有兴趣。有这种态度的网站值得赞赏，但如果仅仅如此的话，还是不够的。

如果省略了服务器方面的计算，攻击者只要从数据库中拿到客户端计算出的 sha256(password+salt) 的结果，原封不动的传给服务器，仍然可以模拟登录。所以无论客户端提交的是原始密码，还是加工后的密码，服务器都应该继续加盐「烹饪」后再使用。

3. 客户端和服务端都对密码进行加工，还有泄漏原始密码的风险吗？

还是有的。毕竟入侵网站拿到服务器数据是困难的，而广撒渔网入侵普通用户的电脑可能会容易一些。木马程序记录用户的键盘输入，原始密码仍然会被窃取。常见而有效的办法是，网站记录用户的登录地点、时间、频率等特征，一旦发现异常登录即刻限制账户的操作，可以很大程度上避免用户的损失。

这一切的源头在于用户输入了原始密码。如果网站事先与用户协商，使用随机的一次性密码，就规避了这种风险。比如短信密码， Google 二次验证，以及其他的内置密钥的临时口令生成设备。即便网站不支持这些功能，也可以使用密码管理器来为不同的网站生成不同的密码，避免战线全面沦陷。

还有一种可能，攻击者使用你的帐号和密码字典，加工后不断向服务器尝试登录，或者提交随机密码来碰运气；不过只要网站采取了限制密码尝试次数的措施，就轻松搞定了。如果攻击者在极有限的次数内猜到了原文密码，或者另外一个内容不同、但「烹饪」后的 hash 完全一致的密码，你一定要想办法联系到他，让他写一个彩票号码给你。

4. 使用随机密码就万无一失了吗？

尽管攻击者并不知道你的原始密码，但是他们有可能远程控制你的访问终端。比如使用后门程序操作你的浏览器发送一些敏感的操作请求，入侵你的手机来读取短信内容，甚至直接偷走你的动态令牌设备……

5. 我已经足够小心地管理自己的设备和密码，可以高枕无忧了吗？

少年，不得不提一下中间人攻击了。攻击者污染你的 DNS ，把你的请求劫持到了他们的服务器上，伪装成目标网站。尽管浏览器提示了网站的证书可能有问题，你点击了忽略，继续操作。你要申请短信密码了是么？攻击者会帮你向真正的网站请求短信密码，然后你把短信密码发到了假网站，攻击者就能成功登录了。所以，你需要换一个足够智能和安全的浏览器，并重视浏览器的安全提示。

6. 我终于明白浏览器证书提示的重要性了，还会有其他问题吗？

更厉害的中间人攻击，可能浏览器都发觉不了。比如攻击者设法搞到了一个有效的证书。当然，如果你访问过真的网站，浏览器会察觉到这两个网站的证书稍有不同（ HSTS ）。最倒霉的情况是第一次访问，你和浏览器一起掉进了坑里；很快这将成为一个大新闻的，网站丢了证书声明作废，或者某某证书机构闹了乌龙将证书发给了坏人。你有机会在事后意识自己受到了欺骗。你应该提前关注新闻，学习自己管理设备上的证书，随时告诉设备某某机构是否值得信任。

7. 我搞懂了证书和证书机构，可以无所畏惧了吗？

你访问了网站首页，没有发现问题；在表单上填上了随机密码，页面跳转到加密页面，证书也没有问题，只不过页面提示说密码不正确。注意！你有可能被猪队友坑了。在启用加密链接之前，你的密码在网络上裸奔了一次！你的程序员队友犯了一个错误，将表单提交到了非加密地址，尽管后来跳转到安全链接上了。要是网站使用了 HSTS ，就不会发生这样的情况了。 HSTS 需要访问一次网站才能生效，如果网站加入到了浏览器的内置 HSTS 名单中就最好不过了。

8. 我很靠谱，网站也很靠谱，我的原始密码已经像在核避难场所里一样不怕攻击了吗？

理论上接近了，除非网站使用证书私钥不够长，被越来越厉害的计算机破解，像 HTTP 一样容易监听。你终于安心了，直到有一天，你小手一滑在输入网址的时候敲错了一个字母，或者点击了一个链接，进入了一个域名相似的假网站……

9. 我已练成了金刚指和火眼金睛，试问谁敢与我争峰？

手机来了新消息，老板说把情报系统的密码发给我……你马上回复了短信密码和二次验证码，得，社会工程学，还是防不胜防！

----
以上内容随手一写，有错误请各位指正。

@vertigo 假设未来计算机性能大大提升，但算力仍然有限，那么你的摘要信息是否会被注意到呢？很有可能被淹没了。除非你能明确证明内容的价值，比如获得原文后，能得到大量的比特币奖励。

@flyingghost
@limhiaoing

没有限制条件的话，原文的确不是唯一的。如果给出了长度和内容规则，比如是一首宋词，我不太相信所有解都符合韵律……

@panlilu
@ipconfiger
@ZRS
@hellojinjie
@wevsty

摘要不能从数学上「解密」回原文，但是可以穷举原文来「撞」摘要。