Хранение имени пользователя / пароля во время обработки

Question

Работа в контексте приложения ASP.NET Я создаю страницу, которая сможет выполнять сценарии базы данных для одной из многих баз данных в нашей среде. Для этого нам нужно запросить у пользователя комбинацию имени пользователя и пароля, это значение можно использовать для всех серверов без проблем.

Вопрос в том, где находится наиболее безопасное место для хранения этой информации? Мы должны хранить его временно, так как когда они находятся на этой конкретной странице, они могут выполнять сотни сценариев через несколько обратных передач. Из того, что я могу сказать, у меня есть 3 варианта, и я не уверен, что является лучшим. Ниже я расскажу об опциях, какова рекомендация всех здесь? Что является наиболее безопасным, но при этом дружественным для пользователя?

Информация о магазине в Viewstate

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

Сохранение информации в сеансе

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

Информация о магазине в приложении

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

Почему?

Последний важный вопрос: «Зачем ты это делаешь?». Почему бы нам просто не использовать их идентификаторы Lan? Ну, мы не можем использовать идентификаторы локальной сети из-за отсутствия сетевой поддержки для делегирования.

S0, какое рекомендуемое решение? Зачем? Насколько это безопасно, и мы можем быть?

Обновление

Обширная информация обсуждалась. Чтобы уточнить, мы работаем в среде интрасети, мы не можем использовать олицетворение или делегирование из-за ограничений в сети.

Answer 1

Мне не нравится ни одна из этих идей, но полностью ненавидит идею представления состояния .

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

Answer 2

На мой взгляд, естественным местом для этого является Сессия.

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

Но если вы собираетесь сделать , что , данные могут также находиться во ViewState.

Answer 3

Как писал Джон Макинтайр, для этого следует использовать интегрированную защиту и олицетворение.

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

Answer 4

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

Что касается подходов Session и Application, я не думаю, что подход Application имеет смысл. Данные зависят от пользователя, поэтому Session должен быть подходящим способом. Он исчезнет, ​​как только сессия пользователя будет закрыта. Кстати, если вы решили сохранить его на сервере, используйте SecureString class.

Answer 5

Имя пользователя / пароль действительно не должны нигде храниться.

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

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

Answer 6

Никогда не храните пароли!

Скорее сохраните хэш пароля. Смотри: http://en.wikipedia.org/wiki/Crypt_(Unix)#Library_Function.

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

Answer 7

Хранение в Viewstate увеличивает вашу подверженность, потому что пароль будет летать по Интернету снова и снова. Это зависит от вас, если шифрование достаточно для устранения этого риска.

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