Алгоритм проверки кода сообщения

Question

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

В настоящее время я работаю над проектом, в котором мы будем использовать какой-то алгоритм для проверки пользовательского ввода. Есть три стороны для рассмотрения;

Клиент - Просмотр наших веб-страниц

Компания - Мы обрабатываем запросы клиентов

Сторонняя компания - Обработка клиентских сообщений

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

Лучше всего было бы, если бы мы, Компания, не взаимодействовали со Сторонней Компанией. Чистое шифрование выходит за рамки возможного, потому что оно генерирует слишком длинную строку. Мы делаем это с помощью SMS, поэтому коды должны быть короткими.

То, что я до сих пор придумал:

Для каждого продукта я генерирую несколько уникальный код (не важно, уникален он или нет) в базе 16 (0-f). Клиент, которому нужна дополнительная информация о продукте, отправляет SMS-сообщение сторонней компании с указанием кода продукта. В свою очередь, клиент получает тот же код, но цифры умножаются (возможно, на 2) и преобразуются в базу 36. Кроме того, в код добавляется последний символ, контрольный номер, чтобы сделать код действительным для Luhn алгоритм в базе 36. Пользователь вводит полученный код, и мы, Компания, проверяем его на стороне сервера по коду продукта (проверяем по Луну, делим на 2 и переключаемся обратно на базу 16).

Это звучит достаточно безопасно и уместно? Является ли это допустимым способом отправки сообщений тремя сторонами, когда двум из них не нужно общаться?

Извините за правку, но, наверное, я был где-то в другом месте, когда писал первый пост.

Answer 1

Я думаю, вы что-то путаете, например, если вы используете алгоритм Луна, он просто вернет True или False в контрольной сумме. Пример кода, который вы дали, кажется, указывает на то, что вы хотите получить некоторый результат контрольной суммы (например, 12345), который можно хэшировать из двух разных значений. Эта проблема будет более сложной.

Как третья сторона создаст это значение? Дадите ли вы им код Javascript для выполнения или какой-нибудь другой язык? Не могли бы вы иметь общий секретный ключ, и они могли бы симметрично зашифровать значение с этим секретным ключом, вы могли бы сделать так, чтобы они префиксировали часть, которую они зашифровали, с некоторым известным значением, чтобы вы могли проверить это быстро.

Их код:

  to_send = encrypted(shared_key, 'check' + code)

Ваш код:

  unencrypted = decrypt(shared_key, to_send)
  if not unencrypted.startswith('check'):
    return False # failed check

Answer 2

Изменить после некоторых уточнений :

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

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

Конкретная перестановка алгоритма Луна, на мой взгляд, не слишком важна - если кто-то может взломать один вариант, он, вероятно, сможет взломать другой.

Оригинальный ответ :

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

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

Answer 3

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

Шифратор всегда выдает один и тот же результат с одного и того же ввода.

Затем клиент отправляет вам код продукта и код ключа. Вы запускаете код продукта через точную копию этого шифратора и сравниваете этот результат с кодом ключа.

Безопасность этой системы может быть повышена без изменения основной архитектуры.

-Аль.

Answer 4

ОК, так что вам не нужно взаимодействие между другим приложением и вашим приложением. И вы хотели бы ограничить коды до 6 символов. Вот мои мысли:

• Используйте 10 символов, которые сделают атаки грубой силы сложнее;
• Используйте все латинские буквы и цифры - это даст вам 36 возможных значений символов;
• Почему бы не использовать некоторую библиотеку больших чисел и просто умножить ваш код (взятый как число Base36) на какое-то смехотворно большое значение (скажем, 2048 случайных битов). Затем преобразуйте его в Base36 и возьмите последние 10 цифр. Или, может быть, первые 5 и последние 5. Или, может быть, какая-то другая комбинация, зависящая от исходного кода. Я понятия не имею, насколько криптографически сильным это будет (вероятно, не очень), но усилия по взлому кода, несомненно, будут меньше, чем просто оплата за услугу.
• В качестве альтернативы вы можете засолить (добавить некоторую секретную строку) свой код, а затем вычислить его MD5. Верните MD5 (или несколько его N символов) пользователю в качестве кода. Это должно быть довольно криптографически нормально, хотя я не эксперт. Преобразовав результат MD5 в Base36, вы можете увеличить силу этого алгоритма.

Answer 5

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

Спасибо за ваш вклад.