存储密码以针对另一个系统进行身份验证

发布于 2024-08-09 23:38:04 字数 386 浏览 1 评论 0原文

这不是常见的问题“存储纯文本用户密码安全吗?”。不,这不安全,我们都知道。

我正在编写一个小应用程序,该应用程序应该针对外部系统进行身份验证以执行某些操作,唯一可用的身份验证方法是通过用户名和密码。它是为人类设计的,无法更改。

有多个用户可以访问我的应用程序,并且每个用户都单独进行身份验证,但是他们都针对外部系统“共享”相同的身份验证数据,理想情况下由应用程序透明地管理。

“愚蠢”的解决方案是以纯文本形式存储用户名/密码并使用它进行身份验证,但显然这并不安全。密码可以加密,但如果有人闯入系统怎么办?

可能的解决方案:使用 DPAPI 透明地加密/解密密码(甚至可能是用户名)。这是个好主意吗?这安全吗?多台机器的设置怎么样(机器之间的加密是否兼容)?

您还有其他建议吗?

This is not the usual question "Is it safe to store plain-text users' passwords?". No, it's not safe, we all know that.

I'm writing a little application that should authenticate against an external system to do some stuff, and the only available authentication method is through a username and a password. It was intended for humans, and cannot be changed.

There are multiple users that have access to my application and each one is authenticated separately, however they all "share" the same authentication data against the external system, which ideally is managed transparently by the application.

The "dumb" solution is to store username/password in plain-text and use it for authentication, but obviously this is not safe. Passwords could be encrypted, but what if someone breaks into the system?

Possible solution: use DPAPI to encrypt/decrypt the password (and maybe even the username) transparently. Is this a good idea? Is this safe? What about setups with multiple machines (is encryption compatible between machines)?

Do you have any additional suggestion?

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

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

发布评论

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

评论(3

木緿 2024-08-16 23:38:04

DPAPI 通常不能在网络场中使用 - 密钥存储是特定于计算机的。您没有指定某些用户是否共享一组凭据,而另一个用户是否共享另一组凭据。如果所有用户共享同一组凭据,请将其存储在 web.config 中并使用它。使用配置加密 API 或 web.config 文件中的简单 ACL 保护凭据。

如果不同的用户具有不同的第三方系统凭据,我将使用用户密码的哈希+盐作为加密密钥将凭据与用户一起存储。然后,即使恶意用户获取了您的数据库,他们也必须能够首先解密您的用户密码,然后才能尝试破解第三方密码。盐增加了这样做的额外难度。

DPAPI cannot usually be used in web farms - the key store is specific to the machine. You didn't specify if certain users share one set of credentials while another user shares another set of credentials. If all users share the same set of credentials, store it in the web.config and be done with it. Secure the credentials using either the configuration encryption API or simple ACLs on the web.config file.

If different users have different third party system credentials, I'd store the credentials with the user, using a hash of the user's password + a salt as the encryption key. Then, even if a malicious user gets your database, they'd have to be able to first decrypt your user's password before even attempting to hack the third party password. The salt adds an additional layer of difficulty in doing so.

梦初启 2024-08-16 23:38:04

请记住,DPAPI 密钥位于用户级别。除非您要为每个用户设置并存储单独的凭据集副本,否则 DPAPI 不会给您带来任何好处。唯一真正安全的方法是使用“受信任的子系统”模型,其中您以某个用户身份运行 Windows 服务,并将受保护的数据存储在该用户的 HKCU 配置单元中,并使用其 DPAPI 密钥进行加密。它代表用户对系统执行需要身份验证的所有操作,并且用户名/密码不会加载到用户的进程中。即使如此,如果用户是管理员,他们在技术上仍然可以通过调试服务进程来获取用户名/密码。

真正安全的方法是执行相同的操作,但远程使用 Windows 凭据对用户进行身份验证,让远程服务器代表用户采取操作。实际上只取决于用户名/密码的安全程度。

Remember that DPAPI keys are at the user level. Unless you're going to set up and store a separate copy of the credential set for each user, DPAPI won't do you any good. The only really secure way to do this would be with a "trusted subsystem" model where you have a Windows Service running as some user, with the protected data stored in that user's HKCU hive encrypted with its DPAPI key. It performs all the actions to the system requiring authentication on behalf of the user, and the username/password aren't loaded into the user's process. Even with that, if the user is an admin, they could technically still get ahold of the username/password by debugging the service process.

The really safe way to do it would be to do the same thing, but remote- use Windows credentials to auth the user to a remote server that takes action on behalf of the users. Really just depends on how secure that username/password needs to be.

聽兲甴掵 2024-08-16 23:38:04

您需要保留纯文本用户名和密码以用于登录外部系统。您可以尝试自己加密该文件,然后以某种方式在应用程序中隐藏密钥。

然而,您的操作系统(例如 Windows)可能确实提供了保护文件的方法,并且这些方法很可能是由经验丰富的专家实施的 - 很难建议您投入时间来进行自己的操作!

,最好的方法是将您的凭据存储为纯文本,并依靠操作系统来保护文件,例如,

  • 您的 Web 服务器作为自己的用户运行的加密主目录,这样只有它才能获取其数据
  • 整个磁盘加密。

因此 如果这意味着无人值守,则需要在启动时提供机器/服务“登录”。

这个问题本身包含在安全免责声明中,因此这一点不需要费力。

  • 它将阻止空闲的对等方访问服务器上的终端
  • 它不会阻止访问正在运行的机器和物理设备的专门攻击者(从火线和 USB 设备到冷却剂攻击的所有攻击基本上都是无法防御的)
  • 它赢得了不能阻止这些凭据在您的服务器和它们登录的其他系统之间受到攻击 - 如果其正常的 http 登录到其他系统甚至没有 http-digest 身份验证...

You need to keep the plain-text user-names and passwords available for logging into external systems. You could try and encrypt this file yourself, and then obscure the key somehow in your application.

However, its likely your operating system (e.g. Windows) does offer ways of securing files and its likely that those are implemented by experienced experts - it's hard to recommend investing time in rolling your own!

So the best approach is to store your credentials as plain-text and rely on the operating system to protect the file e.g.

  • encrypted home directories where your web server runs as its own user so only it can get at its data
  • whole disk encryption

Consideration to how the machine / service 'logs on' at start-up will need to be given if this is meant to be unattended.

The question itself is covered in security disclaimers so this point does not need to be laboured.

  • It will keep out idle peers who get to a terminal on the server
  • It won't keep out dedicated attacker with access to the running machine and physical equipment (everything from firewire and usb devices to coolant attacks are basically impossible to defend against)
  • It won't stop these credentials being attacked in-flight between your server(s) and the other systems they are logging into - if its normal http logins to the other systems without even http-digest authentication...
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文