linux自带perl加密,关于加密：如何在Perl脚本中加密或隐藏密码？

我正在研究Perl脚本，它使用Expect通过telnet登录到远程机器(不要问，必须使用telnet)。我还根据需要执行P4登录操作，并使用Expect-to管道输入正确的密码。目前，我只是从明文环境变量(即export PASSWORD=password)中读取密码，我知道这是不明智的安全措施。

对于需要多个系统的大量密码的脚本，存储密码的最佳方法是什么？以某种方式在文本文件中加密？或者别的什么？

请记住，我不能轻易地更改现有系统，例如，我不能真正安装ssh或类似的东西。

您试图防御哪些类型的威胁？在你工作的盒子上，你信任(或不信任)其他用户多少？

我只是开始这个脚本的工作，为了测试的目的，我把它作为纯文本。所以有共享的用户，很多用户共享这个盒子。所以主要是我希望其他用户至少不能随意地读取所有密码。

也许你最好的方法是把密码放在一个单独的文件中，并锁定该文件的安全性，这样只有你有读取权限。不幸的是，如果您在脚本中存储加密的密码，您还必须存储解密方法，这样攻击者就可以运行解密并恢复您的密码。

+1它是唯一合乎逻辑的解决方案，除非您想采用"通过模糊的安全"路径。

@lacqui-您可以在xs中编写(en de)加密代码并编译它，并通过perl与之接口，(为了安全起见)不使用标准的模块分发来分发xs源代码。但即使这样也不完美。

前面有一个非常相似的问题，看我的答案。

简而言之，人类必须摆脱信任链。其他的一切都令人困惑。

如果使用telnet，为什么要担心脚本中的密码？一个假定的攻击者会发现，从网络上捕获数据比从远程机器上捕获更容易，也更容易，而且在任何情况下您都无法对其做任何处理。

这听起来像是一个试图把栅栏放在窗户里，让门摇摆不定的例子。

这是一个很好的观点，我意识到使用telnet是一个坏主意，当然不是我的主意，但并没有在这些方面考虑。你真的是认真的吗？我不在乎？我想我必须关心，因为代码审查等，但有趣的想法，尽管如此。

将原因记录在代码中，推动流程中的更改，并将其记录在代码中。加密密码，然后通过telnet从脚本发送明文，就像用代码写下你的密码，然后在一个满是你不认识的人的房间里大喊大叫。

虽然我同意telnet，但仅仅因为前门的锁坏了并不意味着你就把所有窗户的锁都拆了。当你最后把前门锁修好时会发生什么？

当然有一个平衡。在我看来，这就像是一个有着系统性坏习惯的商店，试图在问题上撒上一点小精灵的灰尘，并称之为"完成"。这就是为什么我提倡记录这些问题，并明确它们之间的相互关系。只有这样你才能修好它们。

为了评估范围，在分段交换网络中读取嗅探密码的问题。这并不简单，所以我认为加密脚本中使用的密码仍然有帮助。我对你的回答投了赞成票，这当然让我想起来了。删除所有的telnet可能是非常昂贵的工作(数百万)。

不过，我应该补充一点，移动到ssh是在这里发生的，并非所有机器都是一夜之间发生的。

我加入了关于telnet是这里最大的问题的讨论。但我认为，当系统不能100%安全时，这种"为什么麻烦"的态度在信息安全领域太普遍了。噩梦般不安全的遗留系统无处不在，它们必须一个问题一个问题地处理。关于窗户/门的比喻，让门敞开并不是不在窗户上加横条的原因。你应该两者兼而有之，但是即使组织或预算的限制使"关门"成为不可能，也没有任何好的理由不关心系统的安全。

另外，对于telnet，如果在某些系统上安装ssh是不可能的，请不要放弃。您至少可以看看明文telnet数据包在网络中的位置。如果你有幸拥有现代交换机和管理它们的人，如果你有幸在一个或两个系统上都有一个额外的以太网卡，那么就把它们放进自己的VLAN中。如果您幸运地拥有一个防火墙或路由器ACL可用，那么就加入第3层和第4层规则限制telnet的来源和去向。

当你使用MacOSX的时候，我发现了从你的钥匙链中获取用户名和密码的好方法。

更新：截至2013年7月22日，链接似乎已断开。下面的bash代码片段显示了我如何使用该技术(下载iTunes销售数据)：

domain="itunesconnect.apple.com"

user="user@example.com"

pass=$(security find-internet-password -ws $domain -a $user)

这里的链接断了…

@迪恩看到更新的答案。

既然您已经在使用expect，那么您应该考虑在包含密码的加密文件上重定向gpg-d。在系统环境变量中存储密码显然是错误的。用于解密GPG文件的密码将在开始时输入，然后从文件中加载所有密码并运行您的资料。然后就完成了，所以密码只在应用程序运行时以明文形式存在。

编辑就像旁注一样，在脚本中输入任何密码都是不好的；请记住，脚本只是一个纯文本文件，这使得查看密码变得非常容易。同样地，即使您编译的应用程序也可以使用"字符串"进行反转，该字符串可以查找代码中包含的字符串(通常是密码)。

所以我假设您的意思是"GNU隐私保护"，它看起来并不存在于我们的盒子中，就您所知，GPG在hpux和solaris上编译没有问题吗？

我不确定gpg是否有solaris和hpux，但是如果它们是基于*nix的框，那么我确定有一个源。

我喜欢前面提到的将密码放在单独文件中的解决方案。此外，您还可以散列实际密码，就像/etc/passwd中所做的那样。尽管根据应用程序的方式，您可能会对所有的哈希键使用相同的哈希键。显然，这种方法的缺点是，必须有人输入hashkey才能运行脚本，而这在批处理环境中是行不通的。

从这个stackoverflow问题开始学习散列技术