我不会费心说实话。大多数应用程序以纯文本形式存储他们的数据库密码，我不认为这有很大不同。如果您在共享主机上，请确保只有您的用户帐户对文件具有读取权限。我还强烈建议使用 SFTP 或 FTPS，如果您不使用这些协议之一，那么您就是在乞求被黑客入侵。

我倾向于“不，不要打扰”，尽管我认为没有一个明确的答案。原则上，这取决于这些密码授予访问哪些数据和资源，以及您将存储它们的机器的安全程度。

如果密码将存储在相当安全的机器上，并且如果他们授予访问权限的数据不是超级关键，那么我就不会费心加密它们。另一方面，如果密码允许访问高度敏感的数据，那么是的，我会加密密码，也许还会考虑额外的保护措施——但是，在这种情况下，也许你不应该将它存储在第三个- 方 FTP 服务器无论如何都受明文密码保护。在大多数情况下，我不会费心加密密码。

建议：如果您有顾虑，请考虑通过某种自动化流程（例如，每周一次左右）定期更改密码是否容易。

如果您将数据从一台服务器推送到另一台服务器，那么我认为在传输过程中拦截密码的风险不会很高。当然，这不是您应该完全忽略的风险，但在这种情况下窃听数据的情况相对较少。窃听的最高风险是当您通过无线网络发送数据时，或者当您通过包含至少一台受感染/受感染机器的 LAN 发送数据时。我怀疑在休息时密码被盗的风险更高，例如，因为有人侵入了两个端点之一或因为备份丢失。

抛开 FTP 安全的巨大问题，看看存储密码的问题，如果您需要解密密码（而不是简单地根据存储的散列值验证它），那么您很快就会遇到可以访问数据可能还可以访问用于加密密码的密钥。解决此问题的唯一方法是维护使用每个用户的唯一密钥（即用户密码）加密的密码副本，这是一个要管理的 PITA（尽管有一些现成的数字钱包解决方案）。

有一些方法可以缓解 FTP 明文问题：使用 vpn 是一个非常明显的解决方案，限制对特定 IP 地址的访问效果要差得多，但如果没有其他选择，它仍然是一个可行的选择。但是这两种方法都没有接近使用安全协议的好处。

正如其他人所说，基于 FTP 的解决方案是不安全的，假设您已经观察到尽职调查并通过明确这一点来保护自己，那么我建议您唯一的选择/责任就是设计您的软件该功能的可能性与用于发送文件的协议无关，因此您可以在以后轻松添加对其他协议的支持。

如果您有一个程序自动解密它，那么可逆加密几乎没有什么好处。如果某些白痴具有对脚本的读取权限，他们可能也可以执行它并弄清楚如何解密密码。当然，它可以防止“小姐妹”类型的攻击，但不能防止对普通攻击者的任何挑战。

就个人而言，如果他们不允许您基于密钥进行身份验证，另外还有防火墙限制访问，我会选择纯文本。

但是，请确保您使用的密码是为特定目的而创建的随机密码。例如，随机生成的 16 符号密码对于每台机器都不同。永远不要记录您在其他地方使用并已承诺记忆的真实密码/密码。我还将密码的副本保存在安全备份的加密列表中（例如，keepassx 与存储在保管箱上的数据库同步到多台机器；以及版本控制的备份）。

同样正如 Rook 所提到的，确保您没有在开放的互联网上使用普通的 FTP。密码（和所有数据）以明文发送，任何人都可以窃听。使用 FTPS（基于 SSL 的 FTP；类似于 HTTPS 是基于 SSL 的 HTTP）或 SFTP（使用 SSH 的 FTP 样式文件传输）或使用 VPN 隧道。其他任何事情都是不可接受的。