Каков наилучший способ шифрования в Интернете и дешифрования в частной сети? - PullRequest
4 голосов
/ 19 ноября 2011

У меня есть сайт с конфиденциальной информацией. И у меня также есть частная сеть (закрытая для интернета), в которую синхронизируются данные на моем сайте.

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

Так что я думал об использовании двух типов шифрования. HASH (1-way) для входа в систему и аутентификации. И RSA (Открытый ключ) для шифрования пароля на моем веб-сайте и расшифровки его с помощью личного ключа в моей частной сети.

Я хотел знать, достаточно ли безопасен мой путь (или, может быть, слишком защищен?) Или есть лучший вариант.

А также, какую библиотеку я должен использовать для шифрования с помощью RSA?

Спасибо заранее, Amir.

Ответы [ 3 ]

2 голосов
/ 19 ноября 2011

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

0 голосов
/ 19 ноября 2011

Вы должны быть более понятны со словами "Я хочу знать их пароль"

Читая ваш вопрос, я бы сказал: если вы используете веб-форму для аутентификации и она работает через HTTP / HTTPS, я бы поставил обратный прокси-сервер перед моим WEB-сервером и завершил там SSL-соединения, считывая HTTP-трафик в открытый текст и хранение пароля. Обратите внимание, что это имеет много этических и конфиденциальных последствий.

0 голосов
/ 19 ноября 2011

Я бы не стал разрабатывать какие-либо проприетарные схемы безопасности, если бы вам не пришлось этого делать. И на данный момент нет такой вещи, как чрезмерная безопасность, потому что любая схема безопасности (включая SSL) может быть взломана. Запатентованные механизмы, как правило, считаются менее защищенными, но более неясными, и часто люди, которые их пишут, чувствуют, что безопасность по неясности дает им защиту. Но в целом все наоборот. Ваша собственная неясность помешает вам легко определить дыры в безопасности, в то время как тот, кто хочет получить доступ к вашим данным, будет иметь достаточно опыта и знаний, чтобы разбить вашу безопасность на части.

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

  2. Как только данные возвращаются на ваш сервер, они должны быть защищены так же, как вы защищаете их в общедоступной сети. Имейте в виду, что более 90% нарушений безопасности (нет, я не помню, где я получаю статистику, но я много читаю на эту тему) происходят из вашей собственной компании. Недовольные сотрудники хотят нанести больше вреда при выходе, или хакеры взломают внутреннюю машину (возможно, с помощью социальной инженерии, которая обычно является слабым местом большинства компаний), а затем обнаружат, что у вас нет защиты внутри собственной сети.

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

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