如何保护消息负载中的凭据?

发布于 2024-10-28 12:10:56 字数 465 浏览 4 评论 0原文

我们在应用程序中使用消息队列(JMS / ActiveMQ)来促进客户端应用程序和服务器应用程序之间的通信。尝试调用服务器应用程序的用户的用户名和密码作为发送到队列的每条消息的一部分从客户端发送。我们希望通过以下方式保护用户凭据(至少是密码):

  • 当消息有效负载打印到日志文件时,它们不可见
  • 当管理员在管理控制台中查看消息时,它们不可见,让他们查看队列的内容
  • 没有人可以使用截获消息中的凭据创建新消息(即使它被屏蔽/散列/加密)。

简单地在客户端屏蔽密码并在服务器端取消屏蔽是不够的,因为有人可以从日志文件或管理控制台拦截屏蔽密码,创建包含恶意数据的新消息,然后发送恶意消息被揭开并在服务器端执行。使用客户端和消息队列之间的安全通道也会存在同样的问题,因为管理控制台仍然会公开密码(屏蔽或未屏蔽)。

是否有任何模式可以管理这种从客户端一直到服务器的数据隐藏/屏蔽,而任何人(甚至消息代理管理员)都看不到数据?

We're using a messaging queue (JMS / ActiveMQ) in an application that is facilitating communication between client applications and a server application. The username and password for the user trying to call the server application are sent from the client as part of each message that is sent to the queue. We want to protect user credentials (at least the password) in the following ways:

  • They are not visible when the message payload is printed to log files
  • They are not visible when administrators look at the messages in an administrative console that let's them look at the contents of a queue
  • Nobody can create a new message using the credentials from an intercepted message (even if it is masked/hashed/encrypted).

Simply masking the password on the client side and unmasking it on the server side would be insufficient, because someone could intercept the masked password from the log files or the administrative console, create a new message with malicious data, then send the malicious message which would be unmasked and executed on the server side. The same problem would exist using a secure channel between the client and message queue, since the administrative console would still expose the password (masked or not).

Are there any patterns for managing this sort of data hiding/masking from the client all the way to the server without anyone (even message broker admins) from seeing the data?

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

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

发布评论

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

评论(1

小鸟爱天空丶 2024-11-04 12:10:56

一种解决方案是使用共享密钥,然后对密码进行加密。为了防止重放攻击,请阅读 Nonce 是什么:http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm。 websphere.express.doc/info/exp/ae/cwbs_noncev6.html

Example 1:

Client Sends:
      Encrypt(username + password + timestamp)
      Timestamp

Server:

Decrypt to get username, password, timestamp
      compare timestamp in encrypted data == unencrypted timestamp
      if timestamp older than N, then reject

This disallows replay attacks outside of the timestamp +- N window.

Example 2:

Client Sends:
       Encrypt( username + password + Nonce )

Server:
       Decrypt to get usernmae, password, Nonce
       check if Nonce was used before (for this username )
       if it was, then reject 

One solution would be to have a shared secret key and then encrypt the password. In order to prevent replay attacks, read up on what a Nonce is: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/cwbs_noncev6.html.

Example 1:

Client Sends:
      Encrypt(username + password + timestamp)
      Timestamp

Server:

Decrypt to get username, password, timestamp
      compare timestamp in encrypted data == unencrypted timestamp
      if timestamp older than N, then reject

This disallows replay attacks outside of the timestamp +- N window.

Example 2:

Client Sends:
       Encrypt( username + password + Nonce )

Server:
       Decrypt to get usernmae, password, Nonce
       check if Nonce was used before (for this username )
       if it was, then reject 
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文