Предложение по передаче данных и шифрованию пароля

Question

Мне нужно внедрить бесплатную схему (без сертификата SSL), которая может отвечать требованиям по передаче, защите и хранению конфиденциальных данных, при условии, что взаимно доверяемая третья сторона недоступна, то есть мы не можем использовать SSL, TLSи т. д. Но это не означает, что я буду внедрять SSL самостоятельно, я все же хотел бы передать части шифрования и дешифрования существующим кодам.

В качестве решения для защиты учетной записи и пароля я разработал следующую схему:

Предположения для наших злоумышленников:

1. полностью осведомлены о протоколе.

2. имеют доступ кБольшой словарь часто используемых паролей.

3. может прослушивать все коммуникации между клиентом и сервером.

4. может перехватывать, изменять и подделывать произвольные сообщениямежду клиентом и сервером.

5. может получить доступ к исходным кодам (включая код шифрования) на стороне клиента.

Решения:

• RSA (шифрование и дешифрование на клиентских и серверных сайтах соответственно, открытый ключ безопасен для передачи, нет риска, если ключ полученхакером.)

• SHA256 / SHA512 / Twice MD5 (Шифрование с привязкой идентификатора пользователя Salt, оба хранятся в базе данных на сайте сервера.Здесь я использую обязательную соль, чтобы избежать использования общего пароля и радуги.)

Регистрация нового пользователя:

1. Сначала сгенерируйте ключи RSA на стороне сервера (сохраняется в сеансе);

2. Отправьте открытый ключ клиенту;

3. Сохраните открытые ключи в переменной javascript;

4. In Во всех последующих запросах используйте этот ключ для шифрования данных и отправки на сервер;

5. Используйте личные ключи, хранящиеся в сеансе, для расшифровки учетной записи пользователя ипароль на стороне сервера;

6. Шифрование паролей с помощью алгоритма одностороннего шифрования со случайной солью (как, по общему мнению, SHA-256 сильнее, чем MD5);

7. Сохранение идентификатора пользователя, хеш-пароля и произвольной соли (привязки идентификатора пользователя) в базе данных (избегайте использования общего пароля и построения специальной радужной таблицы).

Логин существующего пользователя:

1. Первое генерирование ключей RSA на сервереконец (сохраняется в сеансе);

2. Отправка открытого ключа клиенту;

3. Сохранение открытых ключей в переменной javascript;

4. In Во всех последующих запросах используйте этот ключ для шифрования данных и отправки на сервер;

5. Используйте личные ключи, хранящиеся в сеансе, для расшифровки учетной записи пользователя и пароля на стороне сервера;

6. Извлеките хеш-пароль и соль из базы данных, используя учетную запись пользователя;

7. Зашифруйте пароли с помощью алгоритма одностороннего шифрования сполученная случайная соль;

8. Сравните зашифрованный пароль с хеш-паролем, полученным из базы данных;

9. Определите успешный или неудачный вход в систему.

Я новичок в этой части, и мне нужны какие-то профессиональные советы от вас?Схема достаточно безопасна?Большое спасибо.

Answer 1

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

Итак, если вы говорите о общедоступном веб-приложении, которое вы хотите, чтобы ваши пользователи могли просто использовать и использоватьс уверенностью в безопасности, тогда оплата подписанного SSL-сертификата - действительно ваш единственный выбор.Тем не менее, пара замечаний:

1. Упомянутые вами хэши в порядке, но если вы хотите настоящей безопасности, используйте что-то вроде pbkdf2 (Google, и ваши глаза откроются на глубину и сложностьреальная безопасность)
2. Не проверяя подлинность сервера (с целью подписания подписанного сертификата SSL), вы открываете себя для атак «человек посередине».Если кто-то другой может выдать себя за вас и имеет полную возможность «перехватывать, изменять и подделывать произвольные сообщения между клиентом и сервером», тогда им будет просто фишинг любой информации, которую они хотят от ваших пользователей.Так что это проблема, которую вам нужно решить, если вы хотите, чтобы это было полное решение.

Редактировать: Прочитав и подумав больше о том, что вы ищете, я думаю, что я могуесть решение для вас.

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

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

Ваш контент и адрес электронной почты доступны третьим лицам с достаточными навыками и мотивацией.Но из того, что вы сказали, ваш контент, вероятно, не стоит такого количества усилий, и их адрес электронной почты не настолько чувствителен.Но у вас все еще есть шлюз входа между миром и вашим контентом, и вы можете использовать двойную подписку для ограничения спама и т. Д. Вы можете легко расширить такую ​​систему, включив в нее имя пользователя / пароль и использовать SSL, если ваш контентрастет, чтобы потребовать это.

Answer 2

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

Криптография JavaScript все равно недостаточно хороша (см. эту статью ).

Использование SSL / TLS с самозаверяющим сертификатом, по крайней мере, даст вам возможность предоставить этот сертификат своим клиентам вручную или позволить им вспомнить первый сертификат, который они видели (аналогично тому, как это делает большинство людей). делать, когда они подключаются по SSH: они не обязательно проверяют ключ в первый раз, но ищут изменения в последующих подключениях).

Answer 3

Использование открытых ключей для шифрования всех данных приведет к снижению производительности. Асимметричные ключи предназначены только для шифрования небольших объемов данных (например, симметричного сеансового ключа).

Рассматривали ли вы использовать такой механизм, как Kerberos ? Он предназначен для аутентификации в незащищенных сетях. Это резко отличается от того, что вы делаете - посмотрите, и, возможно, это даст вам некоторые идеи.