喷子真的多，我这个阿里黑都看不下去了。

@Rooney 同

@livid 我也遇到过这个 bug

互联网很可怕的一点是：哪怕再小众的圈子都能有人找到同伴聚在一起，然后忽视其他的声音，不同群体的人之间沟通越来越难，最后都是圈地自嗨，撕来撕去毫无意义。

如果不用 ag/rg 这种东西搜索的话，就得自己搭一套分词+索引+搜索的系统了。当你做好了，加个界面，又可以成一套笔记软件了。或者说，试试 Simplenote 吧

看习惯了 Retina，就算是 24 寸 2K，也有点难受，哎

挂代理可以转，但是转了之后更新已购 mac App 的时候会出问题，不知道 10.14 解决没有

iOS 的应用普遍比安卓的大，之前有人分析过了，好像安卓的安装完之后也会变大..

Dropbox 的密码保护实践是：先用 SHA-256 散列密码让长度一致，然后 bcrypt，再用 AES 加密。这应该是比较靠谱的实践，不过是否一定要在前端完成呢？

另外，国外一部分网站要考虑没有 JavaScript 运行环境或者没有启用的用户，这种情况下就算要给前端做也没法做了。

我在这个网站上找到过若干我自己以为不会有第二个人遇到的问题…

@zzzzzzZ 后端存储的时候把密码再加密当然是有意义的。我的意思是，如果说前端实现的各种加密是后面的 0 的话，完整的 HTTPS 就像是开头的 1。在我第一次看到知乎那个问题的时候，一帮人在争论没有这个 1 的前提下怎么自己造轮子比较重要，有点不知道该说什么，所以说话也绝对了点。80 楼说得很好了。

每个应用都有自己独特的要求，比如像 LastPass 这样的，就算有了 SSL，直接发明文密码也不合适。但是对大多数网站而言，恐怕先把传输过程中的安全做好比较要紧。顺便，发 hash 的话怎么做 regex ？我很好奇。

另外，我可从来没有用过 123456 这种东西做过密码：）

不懂就问：像 Enpass 这样靠 iCloud 文件同步的，浏览器插件是怎么从密码库读密码的？

1. 在非 SSL 的情况下，服务端发过来的 JavaScript 代码完全有可能被劫持篡改。所以这种情况下去尝试自己用 JavaScript 实现一套 SSL 不是重复造轮子，而是完全不可行。那为什么浏览器可以安全地实现 SSL ？因为浏览器那部分代码是你下载的时候就内置在里面的。换句话说，如果你用了不安全的途径下载浏览器，理论上也可能被篡改。

2. GitHub 和 Twitter 把密码泄露到日志中的原因应该是某个日志相关的中间件配置不当。正常的 HTTP 日志不会去记录这些 POST、PUT 请求的请求体内容。就算前端不直接传明文密码，遇到这种情况，总不可能说就不算泄露了吧？

3. 前端那个不叫「加密」，叫散列、摘要。知乎上有个和本帖标题差不多的问题，下面一群人义愤填膺地驳斥认为前端「加密」没有意义的人（现在应该排序好多了，见 https://www.zhihu.com/question/25539382/answer/539557939 ），真是替其中某些程序员的老板捏把汗。

4. 有重放攻击这种东西。有些东西多学习下大厂和知名框架的最佳实践就行了。

5. 我觉得需要前端对密码明文处理一下的只有一类情况：就是后端不应该得到用户的明文密码。诚然只要是用了成熟一点的框架的网站肯定都知道把密码通过一些安全的散列（比如 Bcrypt ）之后再存数据库，也不会再去把明文密码存到另一个地方。不过像端到端加密的应用里，你可能不希望服务端在任何情况下看到你的明文密码。

@zzzzzzZ 没毕业。所以是啥机制？

应该有很多人是自己搭博客的。
Medium 更像简书那种

Jekyll 这么遭人厌？