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

Question

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

Это все для симметричного шифрования не/Key метода Public Private. Таким образом, «соль» и «энтропия» являются секретами между клиентом и сервером.

По некоторым причинам я не могу/не использовать протоколы SSL или TLS. Таким образом, нет центра сертификации и т. Д.

Должны использоваться только стандартные функции и методы криптографии (без изобретений).

Данные не отправляются через безопасное (HTTPS) соединение.

Я не могу использовать сеансы здесь, потому что это два разных приложения.

Первый раз - Зарегистрироваться (пользователь вводит новое имя пользователя и новый пароль)

1. стороне клиента
   1. Создать CSPRNG соль для пользователя
   1. Сохранить соль на машине пользователя
   2. Создать энтропия в памяти (base64 временного значения, например [час дня] + [день года])
   3. Почтовый пароль (base64 открытого текста), а соль и энтропия на сервере
2. стороне сервера
   1. Для принятого сообщения от cliet
   1. проверить, если энтропия соответствует (например, с базой64 [часа дня] + [день года]).
   2. Вычислить хэш (SHA1) соли и пароля (base64 открытого текста) - потому что хеширование всегда должно выполняться на сервере.
   3. Сохранить соль и вычисленный хэш в базу данных

В следующий раз - Войти (пользователь вводит свое имя и его пароль)

1. стороны клиента
   1. Читайте соль из машины пользователя
   2. Вычислить хэш (SHA1) соли и ввести пароль (base64 открытого текста)
   3. Почтовый пароль (base64 открытого текста), а соль и вычисленный хэш на сервер
2. сторона сервера
   1. Получение соли и «хранимая хэш» из базы данных
   2. Из полученного сообщения от клиента
   1. Split сообщения на 3-х частей: пароль (base64 из paintext); поваренная соль; «полученный хэш»
   2. Сравните «полученный хэш» с «сохраненным хешем»; если они совпадают, то пользователь является подлинным не хакером

Отправки TemperProof QueryString от пользователя к серверу

1. стороны клиента
   1. Читайте соль из машины пользователя
   2. Создания энтропии в памяти (base64 временного значения, например [час дня] + [день года])
   3. Вычисляет хэш (SHA1) запросаString (base64 открытого текста), а также соль и энтропия
   4. Сообщение querystring (base64 of the сетование внутр), и соль, и энтропии, и вычисленное хэш на сервер
2. стороне сервера
   1. Получение соли из базы данных
   2. Для принятого сообщения от cliet
   1. Split сообщение на 4 части: queryString (base64); поваренная соль; энтропия; 'received hash'
   2. Проверьте, соответствует ли энтропия (например, с базой64 [час дня] + [день года]).
   3. Вычисляет хэш (SHA1) запросаString (base64 открытого текста) и соли и энтропии.
   4. Сравните вычисленный хеш с 4-й частью расщепленного сообщения («полученный хэш»); если они совпадают, QueryString является подлинной

Отправка ответа обратно пользователю с сервера

1. стороне сервера
   1. Compute ответ с использованием базы данных запросов
   2. Получение соли из базы данных
   3. Создайте энтропию в памяти (base64 временного значения, например[час дня] + [день года])
   4. Вычисляет хэш (SHA1) ответа (base64 открытого текста), а соль и энтропия
   5. Ответ на сообщение (base64 открытого текста) и соль, и энтропии, и вычисленное хеш-клиенту
2. стороне клиента
   1. Read соль из машины пользователя
   2. Создание энтропии в памяти (base64 височной значение, например, [час дня] + [день из год])
   3. Разделить полученное сообщение на 4 части: ответ (base64 of paintext); поваренная соль; энтропия; 'received hash'
   4. Проверьте, соответствует ли энтропия (например, с базой64 [час дня] + [день года]).
   5. Вычислять хэш (SHA1) ответа (base64 открытого текста) и соли и энтропии.
   6. Сравните вычисленный хеш с 4-й частью расщепленного сообщения («полученный хэш»); если они совпадают, то ответ является подлинной

Зоны Ниже перечислены недостатки, я думаю. Не могли бы вы посоветовать, как они могут быть исправлены, а также указать другие возможные отверстия?

A) Первый раз - Регистрация: хакер может размещать мусор заполнить базу данных, если он находит энтропии на этапе 1,3

B) следующий раз - Вход: Я не могу придумать способ добавить энтропию хэшированного пароль на шаге 1.2, потому что тогда я не могу сравнить с тем, на базе сервера на шаге 2.2.2

Благодаря

Answer 1

1. Решение заключается в использовании HTTPS с TLS 1.2 и приписывании сертификата, есть бесплатные решения для сертификатов.

2. Использование хэша (SHA1 в данном случае) для защиты пароля не было хорошей безопасной практикой в ​​течение некоторого времени. Для моей справки см. DRAFT NIST Special Publication 800-63B Digital Authentication Guideline.

3. Пароли должны быть защищены итерационным HMAC, а не одним хешем. Для получения дополнительной информации о паролях см. Toward Better Password Requirements от Jim Fenton, см., В частности, слайд 23. Это, похоже, противоречит тренировкам Pluralsight, лучшие практики со временем меняются.

Answer 2

, если вы заботитесь о безопасности вообще, останавливайся ...

то, что вам нужно сделать:

1) забыть о проектировании собственного протокола крипто ... опираясь на хорошо известный крипто также означает, что вы НЕ проектировать такие вещи

2) думать в слоях. .. у вас есть необходимость хранить вещи в секрете при транспортировке их от A до B ... это означает, что у вас есть транспортный уровень ... если вы хотите, чтобы это было обеспечено, есть имя для этого ...
T ransport L ayer S ecurity ->https://en.wikipedia.org/wiki/Transport_Layer_Security

3) когда вы делаете предположения здесь, как «у меня есть 2 приложения, поэтому я не могу проводить сеансы», пожалуйста, укажите, ПОЧЕМУ вы думаете, что это так ... когда вы думаете о вещах вроде однократного входа, вы можете есть много приложений, разделяющих один метод проверки подлинности и даже данные сеанса через кучу разных платформ ... может быть, это просто вы не знаете, что на самом деле у вас есть может есть сеансы ...

4) читать дальше термины, которые вы используете ... вы неправильно поняли энтропию ... нет способа «проверить, соответствует ли энтропия» ... энтропия в связанных с криптованием случаях означает случайность с точки зрения непредсказуемого ввода функции ... если у вас есть что-то вроде дату и время, и даже если вы хэш, это может выглядеть случайным ... но это очень предсказуемо с помощью s omeone с часами ... если связь может быть связана со временем создания значения, то ваше значение не содержит больших количеств энтропии, если оно основано на часах ...опять же, не создавайте здесь свои собственные материалы и не отправляйте энтропийные источники, которые обеспечивают надежную криптографически безопасную случайность (CSPRNG ... не только PRNG)

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

7) хеширование паролей снова ... нЕ настигнуть вас собственный материал здесь ... создать достаточно длинная случайная соль (по крайней мере длина хэша) для каждого пароля. используйте медленную хеш-функцию, такую ​​как PBKDF2 с большим параметром счетчика итераций. причина в том, что он медленно отслеживает пароли ... ваш сервер должен рассчитать это один раз для каждой попытки входа ... злоумышленник должен рассчитать это для каждой попытки тестирования пароля ... вы можете позволить себе пройти тест 200мс ... для атакующего, что означает намного больше оборудования будет необходимо, чтобы взломать ваш пароль для хранения ...

UPD:
вы хотите, вы получите его ...

доказательства концептуальная атака на вашу схему человеком по середине:

клиент: alice
s ервер: боб
взломщика/перехватчик: накануне

1. алиса использует свой знак на обслуживание и создает учетную запись
   1,1 алиса создает CSPRNG соль и магазины, которые в безопасном режиме
   1,2 алиса собирающую произвольное количество энтропия и кодирует его base64
   1.3 alice отправляет пароль (base64 открытого текста), а соль и энтропия - bob
   ------------ перехвачено --------- ----
2. Канун перехватывает связь между Алисой и Бобом и получает знания е ...
   2.1 ... база 64 закодирован пароль -> base64 декодирование -> открытого текста пароль
   2,2 ... соль
   2,3 ... значение энтропии
   2.4 алиса направляет перехваченной связь без изменений Бобу

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

UPD2 :

взгляд на вашем перетекает (открытый текст) сообщения:
Логин:
сообщение пароля (base64 в незашифрованном виде), и соли, и вычисленных хэш на серверОтправки строки запроса от пользователя к серверу:
Сообщение строки запроса (base64 из открытого текста), и соль, и энтропии, и вычисленных хэш на сервер ответа:
Сообщения ответа (base64 из открытого текста), и соли, и энтропия и вычисленный хэш-клиенту

теперь для любого из этих сообщений, давайте посмотрим на то, что информации, кто злонамеренно узнать бы от:

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

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

так что если злоумышленник теперь перехватывает ваше сообщение, как он может изменить запрос, не будучи замеченным? злоумышленник разбивает сообщение, и изменения, что он/она хочет , то он/она computates в forged_hash как sha1 (salt_from_the_original_message, tampered_querystring) и посылает base64 (tampered_querystring), salt_from_the_original_message, entropy_from_original_message, forged_hash к серверу ...

для ответа на него та же сделка:

злоумышленник перехватывает оригинальный ответ, изменения независимо в ответ и пересчитывает хэш на основе известной информации (изменений и исходной соли)