zlowly

深度自带的终端不行吗？有标签页，有透明度，有雷神下拉模式，有远程服务器管理功能，我觉得都不差了。

@EyebrowsWhite sudo 就是让你可以临时以系统管理员 root 身份运行，脚本以 root 用户身份运行，自然脚本里面的一切命令都是 root 来跑的，对于 root 来说哪个用户的文件就算 600 都能查看。

有一种实践方式是，用 root 编写备份脚本，然后/etc/sudoers 里设置允许某个普通用户运行这个脚本。

要从 https 数据中拿到明文密码，一种可行路径是：扫描关键服务器的信息泄漏漏洞->获取服务器私钥->攻击服务器侧其余薄弱服务器（如测试环境）->横向渗透或抓取服务器段流量->解密服务器 https 流量。通过此途径，可以在没有取得关键服务器的管理、修改权限的情况下，仅凭中风险漏洞就能从流量中获得用户密码等信息。
还有更多其它方式。现在复杂的部署环境，我觉得大部分人都只能负责一小块，服务器、网络、WAF 、负载均衡等等不可能都完全由你掌握，例如有些设备由于性能还要求你先卸载 SSL ，光靠 https 一劳永逸不实际。
也许你会认为这是服务器安全加固责任之类问题，和 https 无关，但是在 HW 、会议等敏感时期中一旦出现安全事故，保不准哪位哥们为了减轻责任，就是把你密码明文传输赖上，为了撇清责任你的上级也不一定会为你说话。
是的，HASH 一下它还是有其它风险，但我自己觉得，多做这一步，不是为了保护数据，而是为了不用提桶跑路。

我觉得楼上很多人对数据安全问题还是了解有限，如果你不是这里数据安全领域里摸爬滚打过，就不要轻易下结论。如果你身边有参加过 HW 的，或者打过 CTF 的同学同事，先去和他们请教一下 HTTPS 用明文传输密码的风险，了解一下为何有了你们都觉得安全的 https ，在 CTF 里还是有 wiresharp 分析 https 流量的赛题。

@luxor 目前的安全防护都趋向于零信任安全的理念，你不能指望只靠通讯协议可以完全对抗中间人，https 虽然对通信内容进行加密，但建立 https 过程仍然有很多步骤是有可能钻漏洞获进行中间人攻击的。当然安全的程度也要考虑成本，但是如果你前端采用 HASH 传输几乎就是 0 成本的，为何不做？万一你这个项目出现信息安全事故，遇到严厉的领导或甲方，你就算再怎么辩解这个用户密码不是从你前端漏出去的，追责时这个偷懒行为都够你喝一壶的。

前面说 Hash 传输没意义，这只是从单一系统角度视角考虑的结果。
要知道现在没有系统会保持明文密码，是因为用户密码的泄露，不但对本系统有风险，更是对用户使用的其它系统都照成风险，因为很多人是多个系统登录注册都用同一个密码的。
同理，将用户密码明文传输，就会出现通信链路中通过中间人攻击可能获取到这个密码，给攻击者有机会利用这个密码试探将用户所有可能使用的系统，扩大了用户损失。

@lucasj 附议
我的实践经验也是 find 的 -delete 参数比 xargs 并行删除要快得多