Метод аутентификации

Question

Я пишу сервер-клиентское приложение для получения и публикации пользовательского сообщения.

Думая о методе аутентификации.

1. Асимметричное шифрование, возможно, RSA.
2. Хэш (соль + пароль + «msg» + «идентификатор пользователя»), SHA256
3. HMAC, SHA256. кажется более защищенным, чем метод 2. Также включайте хеширование пароля и данных сообщения.
4. Симметричное шифрование «сообщения» со статическим паролем, хранящимся на обеих сторонах, вероятно, AES.

Нет необходимости в шифровании, поскольку MSG в любом случае будет публиковаться в сети. Поэтому я больше склоняюсь к методам HMAC или PKI.

Я использую Java для отправки запроса (включая любой метод аутентификации, который будет реализован) www.mysite.com/foo?userid=12345&msg=hello&token=abc1234

Python на стороне сервера, чтобы получить запрос и убедиться, что запрос от действительного пользователя.

Проблемы в интеграции и убедитесь, что обе стороны понимают токены аутентификации друг друга. Это большой фактор для меня. И наличие библиотек, доступных на обоих языках, также принимается во внимание.

Или я могу переписать серверную часть в java. (Почему бы не Python? Клиентское приложение должно быть в Java)

Что вы думаете?

---

РЕДАКТИРОВАТЬ: Я бы не рассматривал это как веб-приложение. Приложение не обслуживает любую веб-страницу. Большинство операций не связаны с сетью. Просто клиент-серверное общение идет через интернет. И отправка POST / GET через HTTP - это то, что я считал более простым, хотя и небезопасным способом сделать это. Не стесняйтесь предложить мне любую другую альтернативу.

SSL - это безопасный способ шифрования. Но это не мешает злоумышленнику отправлять сообщения на сервер, навязываемый как пользователь. Любой может инициировать соединение HTTPS. И содержание сообщения не должно быть зашифровано. В любом случае, он будет опубликован онлайн сервером. Мне нужен способ аутентификации сообщения и отправителя.

Пока я склоняюсь к алгоритму HMAC. RSA будет более безопасным, но также требует больше усилий разработчиков. Посмотрим как пойдет.

Спасибо.

Answer 1

Разве вы не можете просто использовать стандартные сокеты SSL для защиты соединения, проверить пользователя с помощью пароля и затем отправить сообщение для публикации? Если клиентов не будет много, вы даже можете использовать самозаверяющий сертификат и поместить его в хранилище ключей в клиентском приложении, чтобы вам не нужно было покупать сертификат у Verisign или кого-либо еще.

Если вы храните хеш пароля пользователя на сервере (как я думаю, в противном случае вы должны проверить пароль пользователя), то вы можете сначала воспроизвести этот хеш на стороне клиента (предположим, вы хешируете пользователя + пройти), а затем добавить это к сообщению и хэшировать результат. Вы отправляете идентификатор пользователя, хэш и сообщение на сервер.

На стороне сервера вы получаете запрос с идентификатором пользователя, извлекаете пароль пользователя (сервер сохранил только хэш user + pass), добавляете его к сообщению и снова его хешируете, и сравниваете его с хеш в запросе. Если оно совпадает, пользователь может опубликовать сообщение.

Да, и вы должны использовать HTTP POST вместо отправки данных по URL. Сервер не должен принимать данные в URL для запроса на публикацию.

Answer 2

Позвольте мне добавить несколько случайных мыслей / комментариев к вашим предложениям.

1. RSA: Поскольку вы в основном заинтересованы в аутентификации, я предполагаю, что вы захотите использовать подписи RSA. Это подразумевает, что каждому пользователю нужен свой собственный приватный ключ. Для меня это звучит немного похоже на излишество, особенно когда пользователь и сервер уже делятся общими секретами (т. Е. Паролями).
2. Использование SHA256 - хороший подход. У меня есть некоторые проблемы, чтобы понять, почему вы включаете соль, так как соль обычно используется, чтобы избежать того, что злоумышленник предварительно вычисляет хеши словарей. Чтобы было ясно: диктаторские атаки являются проблемой здесь. Злоумышленник может попытаться хэшировать сообщения со всеми паролями из словаря. Просто он должен повторить эту атаку для каждого пользователя и не может повторно использовать предварительно вычисленные значения. Один из способов сделать такую ​​атаку немного более сложным называется усиление ключа, например, повторным хэшированием результата n раз и, следовательно, заставляет злоумышленника выполнять больше работы во время атаки по словарю.
3. Я полностью согласен, что HMAC лучше, чем просто SHA-256. Ведь HMAC был разработан для аутентификации. Я не уверен, почему вы хотите хэшировать сообщение перед вычислением HMAC. HMAC сделает это за вас.
4. Шифрование не всегда обеспечивает аутентификацию. Это особенно в случаях, когда злоумышленник изучает открытый текст, как он делает в вашем случае. Он мог бы использовать свойства режима шифрования для манипулирования зашифрованным текстом и точно знать, как будет выглядеть результирующий открытый текст (например, режим CBC допускает подобные манипуляции). Ваше предыдущее предложение (HMAC) является предпочтительным.

Наконец, если вы можете установить SSL-соединение между пользователем и сервером, как предлагают другие: это было бы гораздо более безопасным решением, так как даже упомянутая выше атака по дисионату была бы невозможна.

Answer 3

Хорошо, во-первых, вариант, который стоит рассмотреть, - это просто пойти по пути «корпоративного решения» и купить на стандартном рынке PKI: купите себе сертификат у Veri $ ign и т. Д. И используйте скучный старый HTTPS (или, по крайней мере, TLS, основной протокол). Тогда отправка данных от клиента (более или менее) пустяк, и в любом языке, который вы выберете для интерпретации на другом конце, будет стандартная библиотека. Я на самом деле думаю, что HTTPS / TLS и вся инфраструктура сертификатов - сложная трата пространства для приложений, где вы знаете, с каким сервером вы разговариваете, и знаете, какую систему шифрования вы хотите использовать. Но наличие библиотек "из коробки" означает, что может быстро запустить и запустить вас, поэтому определенно стоит подумать о том или ином.

В принципе, вам не нужен выданный PKI сертификат для использования HTTPS / TLS. Но на практике может быть проще потратить несколько долларов, чем попытаться убедить стандартную библиотеку принять самостоятельно выданный сертификат. (В целом, использование библиотек HTTPS может означать, что вы в конечном итоге превратили 2-дневную проблему «Программирование моей системы шифрования» в 2-дневную «почему этот черный ящик не принимает мой сертификат» - это также отчасти зависит на какую проблему вы хотите решить ...)

Даже если вы не используете HTTPS / TLS, вы можете прочитать спецификацию, чтобы понять, как она преодолевает определенные угрозы безопасности (и что это за угрозы).

ОК, тогда набирайте свои очки:

• Просто чтобы прояснить ситуацию, вам НЕ нужен сертификат или PKI для использования RSA или другого асимметричного шифрования. PKI (попытается) решает проблему клиента, которому нужно общаться с «загадочным» сервером, которому он не может доверять, когда этот сервер говорит «вот мой открытый ключ». Если вы пишете выделенный клиент и заранее знаете, с каким сервером вы общаетесь, вы можете просто распространить открытый ключ вместе с вашим клиентом. Клиент знает, что он обращается к нужному серверу, потому что если бы это было не так, этот сервер не понял бы то, что он зашифровал этим открытым ключом.
• Главное, с чем вам следует быть осторожным при использовании «сырых» хешей, это то, что они уязвимы для атак расширения. Поэтому, если вы отправите «a | b | c» плюс хеш-код для этих данных, злоумышленник может обработать хеш-код для «a | b | c | d» (так что в вашем примере (2) они могут заменить » userid "for" useridX "и разработайте новый хеш-код для этого на основе хеш-кода, который вы указали для" a | b | c "). Схемы HMAC решают эту проблему.
• В любом случае, если вы собираетесь использовать «сырые» инструменты шифрования, все равно используйте стандартные библиотеки, потому что они будут думать о некоторых проблемах безопасности. Например, с RSA вы должны быть осторожны при использовании заполнения (см. Некоторую информацию, которую я написал о RSA-шифрование на Java и в разделе криптографии, в котором он находится - это может вас заинтересовать). И при генерации любого ключа шифрования вы должны быть осторожны с «откуда поступают случайные данные».
• Вам не нужно основывать ключ шифрования AES на пароле (если вы это делаете, ознакомьтесь со схемами шифрования на основе пароля: пароль, как правило, имеет небольшую энтропию, поэтому вам нужно принять дополнительные меры, чтобы попытаться защититься от этого ). Но я бы пошел на более стандартный подход с использованием пароля для аутентификации соединения, и как часть аутентификации, согласование случайного ключа AES.
• Убедитесь, что вы решаете проблему повторных атак в своей схеме (как правило, клиент и сервер должны отправлять друг другу случайный "nonce" в начале связи и аутентификации и будущее общение по этому соединению будет зависеть от одноразового номера).

Answer 4

Протокол RSA обычно используется для настройки обмена ключами для более быстрого шифрования. Вот как работает SSL.

Если требования безопасности для ваших приложений настолько чувствительны, что вам требуется PKI, то следует сказать (без всякого намерения быть резким), что если вам нужно спросить об этом в SO, то, вероятно, вам это не следует попытка сделать (учитывая, что обычно успешные атаки на безопасные каналы атакуют слабые точки реализации).

Как предположил Chochos, что плохого в том, чтобы просто использовать существующую инфраструктуру SSL в Java и ваш сервер для установки безопасного соединения https, а затем просто передать пароль пользователя от клиента на сервер?