Как я могу защитить учетные данные, которые являются частью полезной нагрузки сообщения?

Question

Мы используем очередь сообщений (JMS / ActiveMQ) в приложении, которое облегчает связь между клиентскими приложениями и серверным приложением.Имя пользователя и пароль для пользователя, пытающегося вызвать серверное приложение, отправляются клиентом как часть каждого сообщения, отправляемого в очередь.Мы хотим защитить учетные данные пользователя (как минимум, пароль) следующими способами:

• Они не видны, когда полезная нагрузка сообщения печатается в файлах журнала
• Они не видны, когдаадминистраторы просматривают сообщения в административной консоли, которые позволяют им просматривать содержимое очереди
• Никто не может создать новое сообщение, используя учетные данные из перехваченного сообщения (даже если оно маскировано / хешировано / зашифровано).

Недостаточно просто замаскировать пароль на стороне клиента и снять маску на стороне сервера, поскольку кто-то может перехватить замаскированный пароль из файлов журнала или административной консоли, создать новое сообщение со злонамереннымданные, затем отправьте вредоносное сообщение, которое будет разоблачено и выполнено на стороне сервера.Та же проблема может возникнуть при использовании безопасного канала между клиентом и очередью сообщений, поскольку административная консоль будет по-прежнему предоставлять пароль (замаскированный или нет).

Существуют ли какие-либо шаблоны для управления такого рода сокрытием / маскированием данныхот клиента до сервера, чтобы никто (даже администраторы брокера сообщений) не видел данные?

Answer 1

Одним из решений было бы иметь общий секретный ключ, а затем зашифровать пароль.Чтобы предотвратить повторные атаки, прочитайте, что такое 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