小硬盘是贵的，成本占了大多数。2T 卖 300 ，1T 也差不多卖 300 ，再往下要是有 0.5T 甚至 0.1T 的可能也得卖 300 。
往上你要找便宜的，12T 的二手盘也出过六七百的价格。

@wangxiang86 对，我忘了扣掉本金了，应该是 15-5=10 万利息。

相当于省下了 5 万块本金对应 28 年的利息。4%的 28 年是 3 倍，还 5 万差不多等于省下 15 万利息？

重度 Git 用户，日常使用 SmartGit 。

是 AI 读了高质量的技术内容以后才写出来的。大家都不写高质量内容的话，AI 读西北风去呢。

啊？ 799 ？官网 16+512 现在是 699 啊？我是首发买的，有个 coupon -30 ，最后是 669 到手，折算下来 4852 。京东同配置不打折是 4799 ，打折是 4059 ，美中差价就是一个京东折扣补贴的差距。

你如果只是想要纯净系统的话，买国行回来刷海外 ROM 就完事了。如果刚需 esim 和海外频段才考虑买国际版吧。

> 等你在什么都没点开的情况下也中了勒索病毒、盗号木马，造成了很大损失，你也会重视的

这不就是 CPU 侧信道攻击吗？插了 CPU 的全中招了。

你自始至终都没有对 Before 和 After 做过具体的案例分析，帖子里基本就是一些假大空的呐喊，什么坚持明文啊什么舒适区啊什么天性啊。怎么不上点干货呢。

这么高一层楼 200 来个回复，说句实话，非常给你面子了，因为讨论的过程还算礼貌，v 站大多数人也不愿意说脏话。换到激进点的论坛里，就不知道是你保卫家人在先，还是管理员看不下去直接 ban 号在先了。帖子内容太过贫乏，甚至激不起我一点讨论技术的欲望。有句话叫，非蠢即坏。看你讨论过程，好像也不像是坏，那可能只是真不懂了。但最可怕的是不懂还觉得自己是对的，有一种老子说的才是对的，你们不同意那一定是你们都是傻逼。那这就没法聊下去了。

大家的耐心是有限的，有些人「蠢」，是因为缺乏知识，旁人点拨一下，去学习了知识，懂了，就不「蠢」了。有些人坚持自己错误的想法，大家劝了劝，发现没什么用，那只好 block 之，以免浪费自己时间。

看到这种纯粹引战的 append ，我的耐心已经用完了。觉得自己老牛逼了，看别人都觉得傻逼的人，我诚挚建议你，以一种圆润的动作姿态离开这个看法和你不同的人组成的社区。

言尽于此，block 了，请勿再回，我不会收到提醒，也不会再浪费更多的时间在这个帖子里了。

@lesismal
> 你有没有想过, 很多黑产搞到东西, 但每年我们看到的新闻有多少? 被你知道的泄漏了的只是冰山一角, 你没看到不代表明文就安全了, 也不代表改造后就没带来更全的安全性.

谁出钱谁说了算。你出钱吗？你不出，所以你说了不算。

你尽管叫破喉咙，但破喉咙是不会来理你的。决定企业做什么的是企业的老总，是 org 的负责人，是 PM ，是 tech lead ，不是你。当然你可以自愿加班去完成我上面说的那些，但这关我什么事呢。你是想说服我无偿加班给公司项目加这个功能吗？我可太谢谢你了。

在资本的社会里谈理想，你的想法是不是有点太甜了。

其实刚刚又想到个事。
加密通信的时候，加密的算法和代码要不要保密或者混淆？
可能有人会觉得，加密算法当然应该保密，攻击者拿不到加密解密方法，那不就安全了吗。

但……

针对 append 部分
一共三个 part: client 端的安全, 传输信道的安全, 传输信道之后的 server 端所有流程的安全. 这其中不只是技术本身的算法流程, 最高可以到社工范畴
你们很多位, 只盯着 1 或者 2 个 part 说没用. 但目的是让完整链条的安全级别提高.
即使不用明文并且增加各种额外手段也不能 100%, 比如绑架了. 但用明文是为了在技术上让完整链条 3 个 part 的整体安全级别更强一些.
所以, 我建议各位, 不要只拿出一个 part 来说用这用那都没用.

==========

我感觉你说了这么多还是没讲到点子上。我觉得你最好重新整理一下自己的思路，否则就我看评论区的样子大家都在各说各话，讨论不到一块儿去。

就拿我司我们 org 的习惯来说吧。如果你要做一项比较大的功能改动（你说的前端加密就已经是比较大的改动了），一般需要先开一个 wiki page 把改动写在文档里。
文档分几个部分，首先是摘要，说明现状如何，遇到了哪个具体的问题，会造成什么样的后果，产生什么样的经济影响。（比如出了一个 bug 造成 3 个客户的业务离线各 3 小时，这就是经济影响。）然后是你的大体设计，这里一般简单说几句画个流程图什么的就行了。然后是产生的实际影响，比如说原本一个 bug 造成某个操作需要花 3 小时跑完，修复了 bug 只要 1 小时就能跑完，等等。

从我读你帖子和回复的内容来看，我并没有看到（ 1 ） HTTPS+明文这样的设计会造成很大的经济影响（例如大规模密码泄露，账号被盗等等），（ 2 ）你设计的解决方案会产生什么样的经济影响（例如原本 v 站大量账号被盗，经过你事故分析，确定是明文传输造成的，如果做了你这个方案，账号就不会被盗了等等）。

如果这是你自己的个人项目，躺在沙发上看电视无聊了突然一拍脑瓜想到了这个方案，爬起来给自己网站加上，这倒是无可厚非的。但是对于正规的企业级项目来说（不管是 GitHub 也好百度也好还是 Amazon 也好），一个 Jira 的立项是需要 business justification 的。就拿我们组的项目来说，修改一处很小的逻辑，也要经过（ 1 ）事故单或者 Filer 提需求（ 2 ）需求分析并撰写 wiki page （ 3 ） Manager 和 Tech lead 审核批准，如果是跨部门的单子还需要其他部门的底层员工和 Manager 签字（ 4 ）确定上线时间，和 Release Management 沟通（ 5 ）写代码，然后为代码写测试覆盖（ 6 ） Peer review （ 7 ）开服务器然后组内测试（ 8 ） FullTest 自动化测试（ 9 ）质量控制组人工测试（ 10 ）运维组人工测试（ 11 ） Demo tenancy 上线测试（ 12 ）分批灰度上线测试（ 13 ）完整上线，正式结案。

当然，不同公司规模不同，流程也不尽相同，但归根结底不要忘记了，加个功能不是拍个脑瓜公司就批给你那么多人工的，工程师又不是天天闲着没事干，处理更高等级的任务都忙死了，为什么要浪费时间处理一个无所谓有无的东西，除非你能说服你的 Manager ，不做这件事就会造成公司损失，否则没人会鸟你。

个人项目，还是那句话，你想做尽管做就是。但不要随便把手指指向别人的项目。这种行为我们有个很常见的说法，叫外行指导内行。

@cybort #160 你说的没错，所以才需要推广密码管理器，一站一码。
前端加密不是解决明文存储密码的方案。毕竟，都为了安全去搞前端加密了，怎么还会去明文存储密码呢……

看了你贴的知乎讲 github 和百度的那个帖子。但是有趣的地方就在于，百度的登录请求的那张图里，其实并没有做过 MITM 中间人防护。也就是说，虽然客户端找服务器拿了公钥，加密了密码然后再发回，但其实客户端并不知道拿到的这个公钥是真的由百度发出。HTTPS 证书世界里，要伪造可信证书是很难的，要是哪个厂敢生成他无权生成的可信证书，没几天他的 CA 就要被全球吊销了。但帖子里讲的这种非对称加密就没有这种认证机制。如果有人有心去主动攻击百度的登录服务，这种额外的加密是不堪一击的，攻击者只要自己生成秘钥对替换掉百度的公钥，然后从用户侧拿到数据解密即可完成密码破解。

其实这帖子我看得很懵，不知道你这个操作到底是要达成一个什么样的效果。

现在我们假设用户的密码是 "3m&y5oDChc"，然后你用 JavaScript 做了一次运算，比如说 md5(password+SALT)，得到 "123456abcdef" 这个 md5 。

你的目标是保护 "3m&y5oDChc" 不被人偷看去，是这个意思吗？

@lesismal 哈希加盐以后，哈希加盐的结果就是密码明文了。

所以你只是想保护用户自己想出来的密码不会被人看见，而不是保证一个能通过认证的密码不被人偷走，是这个意思吗？

我看了看你引用的原贴，似乎是浏览器插件读取了密码。这其实就是一个很典型的明文密码加密无效的案例。盗取密码的攻击者直接把你输入到文本框里的密码读出来盗走就行了，总不能特地等到你前端加密完了再傻傻地去读加密后的密码串吧。

这种你要防的话就要回到 ActiveX 控件密码输入盘的年代了，安全控件读不到文本框的内容，输出直接就是加密的，这才有意义。