Улучшить мой алгоритм / метод общего секрета и предложить протокол шифрования

Question

Я ищу протокол / алгоритм, который позволил бы мне использовать общий секрет между моим приложением и HTML-страницей.

Общий секрет предназначен для обеспечения доступа к веб-странице только людям, у которых есть приложение.

Моя проблема: Я не знаю, какой алгоритм (моя методология для проверки правильности доступа к странице HTML) и какой протокол шифрования я должен использовать для этого.

Люди предложили мне использовать HMAC SHAXXX или DES или AES, я не уверен, что мне следует использовать - есть ли у вас какие-либо предложения?

Мой алгоритм такой:

• Я создаю общий секрет, о котором знают приложение и HTML-страница (назовем его «MySecret»). Чтобы гарантировать, что этот общий секрет всегда уникален, я добавлю текущую дату и минуту к концу секрета, затем хеширую его, используя алгоритм / протокол XXX (HMAC / AES / DES). Таким образом, незашифрованный секрет будет «MySecret08 / 17 / 2011-11-11» и, скажем, хеш этого значения - «xyz»
• Затем я добавляю этот хеш к CGI URL: http://mysite.com/comp.py?sharedSecret=xyz
• Затем сценарий comp.py использует ту же комбинацию общего секрета и даты, хэширует ее, а затем проверяет, совпадает ли полученный хеш с переменной CGI sharedSecret ("xyz"). Если это так, то я знаю, что действительный пользователь заходит на веб-страницу.

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

Я думаю, что я на правильном пути, используя общий секрет , но моя методология проверки секретности кажется ошибочной, особенно если алгоритм хеширования не дает один и тот же результат для одного и того же ввода все время .

Answer 1

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

Тогда хэш нарушается. Почему бы и нет?

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

Обратите внимание, что это все еще несовершенно. TLS поддерживает поддержку сертификатов на стороне клиента и сервера - почему бы не использовать это?

Answer 2

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

Google это: Kerberos, SPNEGO и HTTP 401 Требуется авторизация.Возможно, вам удастся избежать использования простых жестко закодированных имен пользователей и паролей HTTP-заголовков и запускать ваши соединения по протоколу HTTPS.Таким образом, на вашем сервере будет меньше нестандартного кода, и ваш сервер позаботится об аутентификации ваших запросов.Не говоря уже о том, что вы используете некоторые дополнительные возможности HTTP.

Answer 3

Похоже, это будет работать.Смещение часов может быть проблемой, вам может понадобиться проверить диапазон, скажем, +/- 3 минуты, если он не срабатывает в течение точного времени.

с ошибками, особенно если алгоритм хеширования не даетодин и тот же результат для одного и того же ввода все время

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