在类似 Linux/UNIX 的纯文本文件中隐藏网络代理密码

发布于 2024-07-05 05:42:02 字数 677 浏览 8 评论 0原文

通常,在大型网络中,计算机需要在经过身份验证的代理后面运行 - 与外界的任何连接都需要用户名/密码,这通常是用户用于登录电子邮件、工作站等的密码。

这意味着必须输入网络密码在 apt.conf 文件中,以及通常在 ~/.profilehttp_proxy、ftp_proxyhttps_proxy 环境变量code>

我意识到使用 apt.conf 可以设置 chmod 600 (Ubuntu/Debian 上不是默认设置!),但在我们的系统上有人谁需要 root 权限。

我还意识到,从技术上讲,不可能保护具有 root 访问权限的人的密码,但是我想知道是否有一种方法可以隐藏密码以防止意外发现。 Windows 以管理员身份运行,但以某种方式存储网络密码(可能存储在注册表深处,以某种方式隐藏),因此在典型使用中,您不会以纯文本形式偶然发现它,

我只是从前几天开始询问,我完全是偶然的在跨系统比较配置文件时通过这种方式发现了别人的密码。

@monjardin - 恐怕公钥身份验证不是这个网络上的替代方案。 另外,我怀疑大多数命令行工具是否支持它。

@Neall - 我不介意其他用户具有网络访问权限,他们可以使用我的凭据访问网络,我只是不希望它们以纯文本形式出现在我的密码中。

Typically in a large network a computer needs to operate behind an authenticated proxy - any connections to the outside world require a username/password which is often the password a user uses to log into email, workstation etc.

This means having to put the network password in the apt.conf file as well as typically the http_proxy, ftp_proxy and https_proxy environment variables defined in ~/.profile

I realise that with apt.conf that you could set chmod 600 (which it isn't by default on Ubuntu/Debian!) but on our system there are people who need root priveleges .

I also realise that it is technically impossible to secure a password from someone who has root access, however I was wondering if there was a way of obscuring the password to prevent accidental discovery. Windows operates with users as admins yet somehow stores network passwords (probably stored deep in the registry obscured in some way) so that in typical use you won't stumble across it in plain text

I only ask since the other day, I entirely by accident discovered somebody elses password in this way when comparing configuration files across systems.

@monjardin - Public key authentication is not an alternative on this network I'm afraid. Plus I doubt it is supported amongst the majority of commandline tools.

@Neall - I don't mind the other users having web access, they can use my credentials to access the web, I just don't want them to happen across my password in plain text.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(9

苏佲洛 2024-07-12 05:42:02

我做了一个修改后的解决方案:

编辑 /etc/bash.bashrc 并添加以下行:

alias myproxy='read -p "Username: " USER;read -s -p "Password: " PW
PROXY="$USER:[email protected]:80";
export http_proxy=http://$PROXY;export Proxy=$http_proxy;export https_proxy=https://$PROXY;export ftp_proxy=ftp://$PROXY'

从下次登录时输入 myproxy 并输入您的用户/密码组合! 现在使用sudo -E

-E, --preserve-env
指示用户希望保留其权限的安全策略
现有环境变量。

例如 sudo -E apt-get update

备注:代理设置仅在 shell 会话期间有效

I did a modified solution:

edit /etc/bash.bashrc and add following lines:

alias myproxy='read -p "Username: " USER;read -s -p "Password: " PW
PROXY="$USER:[email protected]:80";
export http_proxy=http://$PROXY;export Proxy=$http_proxy;export https_proxy=https://$PROXY;export ftp_proxy=ftp://$PROXY'

From next logon enter myproxy and input your user/password combination! Now work with sudo -E

-E, --preserve-env
Indicates to the security policy that the user wishes to reserve their
existing environment variables.

e.g. sudo -E apt-get update

Remark: proxy settings only valid during shell session

纵情客 2024-07-12 05:42:02

通过以下方法,您永远不必以纯文本形式保存代理密码。 当您需要 http/https/ftp 访问时,您只需以交互方式输入密码:

  • 使用 openssl 将纯文本代理密码加密到文件中,例如使用 AES256 加密:

openssl enc -aes-256-cbc -in pw.txt -out pw.bin

  • 使用(不同的)密码保护编码文件
  • 删除纯文本 pw.txt
  • 在 ~/.alias 中创建别名以设置 http_proxy/https_proxy /ftp_proxy 环境变量(为 $USER/proxy/$PORT 设置适当的值)

alias myproxy='PW=`openssl aes-256-cbc -d -in pw.bin`; PROXY="http://$USER:$PW@proxy:$PORT"; 导出http_proxy=$PROXY; 导出 https_proxy=$PROXY; 导出 ftp_proxy=$PROXY'

  • 您应该将此文件导入到正常的 shell 环境中(在某些系统上,这是自动完成的),
  • 输入“myproxy”并输入用于加密完成的文件的 openssl 密码

注意:密码在 shell 会话期间在用户环境中可用(并且可读)。 如果您想在使用后将其从环境中清除,可以使用另一个别名:

aliasclearproxy='导出http_proxy=; 导出 https_proxy=; 出口
ftp_proxy='

With the following approach you never have to save your proxy password in plain text. You just have to type in a password interactively as soon as you need http/https/ftp access:

  • Use openssl to encrypt your plain text proxy password into a file, with e.g. AES256 encryption:

openssl enc -aes-256-cbc -in pw.txt -out pw.bin

  • Use a (different) password for protecting the encoded file
  • Remove plain text pw.txt
  • Create an alias in e.g. ~/.alias to set your http_proxy/https_proxy/ftp_proxy environment variables (set appropriate values for $USER/proxy/$PORT)

alias myproxy='PW=`openssl aes-256-cbc -d -in pw.bin`; PROXY="http://$USER:$PW@proxy:$PORT"; export http_proxy=$PROXY; export https_proxy=$PROXY; export ftp_proxy=$PROXY'

  • you should source this file into your normal shell environment (on some systems this is done automatically)
  • type 'myproxy' and enter your openssl password you used for encrypting the file
  • done.

Note: the password is available (and readable) inside the users environment for the duration of the shell session. If you want to clean it from the environment after usage you can use another alias:

alias clearproxy='export http_proxy=; export https_proxy=; export
ftp_proxy='

感情洁癖 2024-07-12 05:42:02

首选与 Gnome Keyring 集成的应用程序。 另一种可能性是使用通往外部计算机的 SSH 隧道并通过该隧道运行应用程序。 看一下用于创建本地 SOCKS 代理接口的 -D 选项,而不是单服务 -L 转发。

Prefer applications that integrate with Gnome Keyring. Another possibility is to use an SSH tunnel to an external machine and run apps through that. Take a look at the -D option for creating a local SOCKS proxy interface, rather than single-serving -L forwards.

茶色山野 2024-07-12 05:42:02

除非您使用的特定工具允许混淆格式,或者您可以创建某种工作流程以根据需要从混淆变为简单,否则您可能不走运。

在这种情况下,我看到的一件事是创建每服务器、每用户或每服务器/每用户专用凭据,这些凭据只能从特定 IP 访问代理。 它不能解决核心混淆问题,但可以减轻某人看到密码的影响,因为它的价值很小。

关于后一个选项,我们在工作中提出了一种“反向加密”密码编码,我们将其用于此类内容。 这只是混淆,因为解码密码所需的所有数据都存储在编码字符串中,但它可以防止人们意外看到纯文本形式的密码。 例如,您可以以这种格式存储上述密码之一,然后为 apt 编写一个包装器,动态构建 apt.conf,调用真正的 apt,并在退出时删除 apt.conf。 您仍然会在一段时间内得到明文的密码,但它会最小化窗口。

Unless the specific tools you are using allow an obfuscated format, or you can create some sort of workflow to go from obfuscated to plain on demand, you are probably out of luck.

One thing I've seen in cases like this is creating per-server, per-user, or per-server/per-user dedicated credentials that only have access to the proxy from a specific IP. It doesn't solve your core obfuscation problem but it mitigates the effects of someone seeing the password because it's worth so little.

Regarding the latter option, we came up with a "reverse crypt" password encoding at work that we use for stuff like this. It's only obfuscation because all the data needed to decode the pw is stored in the encoded string, but it prevents people from accidentally seeing passwords in plain text. So you might, for instance, store one of the above passwords in this format, and then write a wrapper for apt that builds apt.conf dynamically, calls the real apt, and at exit deletes apt.conf. You still end up with the pw in plaintext for a little while, but it minimizes the window.

瑾兮 2024-07-12 05:42:02

公钥身份验证对您来说是一个有效的替代方案吗?

Is public key authentication a valid alternative for you?

黑色毁心梦 2024-07-12 05:42:02

只要这三件事都是正确的,你就不走运了:

  1. 服务器需要 Web 访问
  2. 用户需要对服务器的绝对控制权(root)
  3. 你不希望用户拥有服务器的 Web 访问权限

如果你不能删除 #2或#3,您唯一的选择是删除#1。 设置托管所有软件更新的内部服务器。 将该服务器与其他用户隔离,并且不允许其他服务器访问 Web。

你尝试做的任何其他事情都只是在欺骗自己。

As long as all three of these things are true, you're out of luck:

  1. Server needs web access
  2. Users need absolute control over server (root)
  3. You don't want users to have server's web access

If you can't remove #2 or #3, your only choice is to remove #1. Set up an internal server that hosts all the software updates. Keep that one locked down from your other users and don't allow other servers to have web access.

Anything else you try to do is just fooling yourself.

晨光如昨 2024-07-12 05:42:02

我们通过在 rpm、apt 或其他类似更新(病毒数据库、Windows 等)上不要求代理密码来解决这个问题
这是要添加到代理的已知存储库的小白名单。

we solved this problem by not asking for proxy passwords on rpm, apt or other similar updates (virus databases, windows stuff etc)
That's a small whitelist of known repositories to add to the proxy.

十六岁半 2024-07-12 05:42:02

我想您可以创建一个本地代理,通过该代理指向这些工具,然后让本地代理以交互方式询问用户输入外部代理密码,然后应用该密码。 它可以选择在模糊的内部存储中记住这一点几分钟。

一个明显的攻击媒介是特权用户修改此本地代理以使用输入的密码执行其他操作(就像他们可以使用其他任何东西,例如请求密码的电子邮件客户端或窗口系统本身一样),但至少您'避免无意中查看。

I suppose you could create a local proxy, point these tools through that, and then have the local proxy interactively ask the user for the external proxy password which it would then apply. It could optionally remember this for a few minutes in obfuscated internal storage.

An obvious attack vector would be for a privileged user to modify this local proxy to do something else with the entered password (as they could with anything else such as an email client that requests it or the windowing system itself), but at least you'd be safe from inadvertent viewing.

温柔女人霸气范 2024-07-12 05:42:02

有很多方法可以隐藏密码:您可以以 rot13 格式或 BASE64 存储凭据,或者使用相同的 密码加扰算法。 但真正的技巧是让您的应用程序了解加扰算法。

对于 ~/.profile 中的环境变量,您可以将它们编码存储,然后在设置变量之前对其进行解码,例如:

encodedcreds="sbbone:cnffjbeq"
creds=`echo "$encodedcreds" | tr n-za-mN-ZA-M a-zA-Z`

这会将 creds 设置为 foobar:password,然后您可以将其嵌入到 http_proxy 等中。

我假设您知道这一点,但需要重复一遍:这不会增加任何安全性。 它只是防止无意中看到其他用户的密码。

There are lots of ways to obscure a password: you could store the credentials in rot13 format, or BASE64, or use the same password-scrambling algorithm that CVS uses. The real trick though is making your applications aware of the scrambling algorithm.

For the environment variables in ~/.profile you could store them encoded and then decode them before setting the variables, e.g.:

encodedcreds="sbbone:cnffjbeq"
creds=`echo "$encodedcreds" | tr n-za-mN-ZA-M a-zA-Z`

That will set creds to foobar:password, which you can then embed in http_proxy etc.

I assume you know this, but it bears repeating: this doesn't add any security. It just protects against inadvertently seeing another user's password.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文