@twl007 为什么我看到最高赞的回答恰恰是支持我的观点的 😂

This is an old question, but I felt the need to provide my opinion on this important matter. There is so much misinformation here

The OP never mentioned sending the password in clear over HTTP - only HTTPS, yet many seem to be responding to the question of sending a password over HTTP for some reason. That said:

I believe passwords should never be retained (let alone transmitted) in plain text. That means not kept on disk, or even in memory.

People responding here seem to think HTTPS is a silver bullet, which it is not. It certainly helps greatly however, and should be used in any authenticated session.

There is really no need to know what an original password is. All that is required is a reliable way to generate (and reliably re-generate) an authentication "key" based on the original text chosen by the user. In an ideal world this text should immediately generate a "key" by salting then irreversibly hashing it using an intentionally slow hash-algorithm (like bcrypt, to prevent Brute-force). Said salt should be unique to the user credential being generated. This "key" will be what your systems use as a password. This way if your systems ever get compromised in the future, these credentials will only ever be useful against your own organisation, and nowhere else where the user has been lazy and used the same password.

@twl007 要是 HTTPS 就够了要那么多安全等级标准干什么，一个标准就够了

@twl007 拦截篡改你也得知道改哪儿才行。

@fox0001 jumpserver 就挺好

有一些开源的跳板机系统，权限管理带 webui 的

@Chihaya0824 只需要套一层非对称加密就行。因为 HTTPS / TLS 中验证公钥是基于证书链的，在不受信任的电脑上会很容易被中间人攻击。但是自己分发公钥就不一样了，可以固定写在源码里，也可以单独下发。别人想中间人攻击得改你的源码（下发响应），无疑是增加难度的。 使用标准 HTTPS 别人一旦针对 HTTTPS 做中间人，所有网站都跑不掉。你自己专有的加密逻辑，工攻击者需要专门针对你的代码逻辑进行攻击。

具体实践可以参考微博登录，就是使用了 RSA 加密后传输。

Qps 相差 40 倍，带宽却几乎差不多。顺着这个往下查就行了

这楼真能看出程序员平均水平…

@twl007 囧 无言以对 不想反驳了

@Chihaya0824 想怎么分发就怎么分发呀，HTTPS 基于 tls 就能替代 tls 了？

`我网上搜了搜，觉得前端目前拿不出什么方案加密比 https 安全`

-- 没搜到非对称加密方案？

如果是急诊可以快，你这种不是很急只能等着了

stoplight 了解一下

推荐 stoplight 客户端

@IvanLi127 测试 加 SWAP 可行，目前没再挂过了

@makelove 我试试你的

@makelove 加了 2g 实际跑到 2.9G 不知道为啥没生效

PS：机器本身 8G ， 还跑了 Jenkins 占 1-3G 左右。每次挂的其实不是 node 进程，而是 Jenkins 。 观察到内存一大飙起来 Jenkins 先挂了，导致构建也失败了。 也不知道为啥杀进程策略每次都是先杀 Jenkins 。Jenkins 重启之后刚开始内存还不大，这时候立即构建一次一般能成功。

@rabbbit 只有一个呢.. 怎么分析是 构建哪个库 的问题？删掉一些依赖 试试？