Совместное использование логин-системы между классическим ASP и ASP.Net

Question

Клиент использует классический ASP для входа в свой веб-офис.

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

Логины и пароли хранятся в виде открытого текста в базе данных SQL Server, к которой я могу получить доступ из моего приложения ASP.Net.

Каким был бы эффективный способ интеграции этих систем?

Моя лучшая идея: В ссылке на мое приложение ASP.Net я указываю на страницу входа «шлюза» с их идентификатором пользователя и хешированным паролем + общий секрет в строке запроса. Затем я сравниваю это с паролем пользователя в базе данных ... Но проблема в том, что если эта строка запроса будет перехвачена, ее можно использовать для доступа к сайту asp.net, фактически не зная имени пользователя и пароля ...

Скорее всего, я пропускаю что-то простое.

Answer 1

Я думаю, ваша идея на правильном пути.

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

Что бы я сделал: при входе в систему создайте уникальный GUID, который вы сохраните в базе данных для этого пользователя. Когда вы переходите с одного сайта на другой, передайте этот GUID в строку запроса. Когда вы попытаетесь автоматически войти на другой сайт, найдите этот GUID и посмотрите, не привязан ли он к кому-либо. Если это так, войдите в систему.

Таким образом, вы не пропускаете ничего, что мог бы угадать или расшифровать пользователь.

Answer 2

Как классическая система ASP поддерживает состояние входа в систему? Безусловно, это было бы лучшим выбором для вас.

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

---

Поскольку информация хранится в классическом сеансе ASP, не могли бы вы добавить «страницу перенаправления» к классической стороне ASP, которая является «входом» в новый модуль, и заставить ее записывать полезные данные как куки или запуск POST на стартовой странице? Используя файлы cookie или запрос POST, вы минимизируете свои опасения по поводу того, что URL-адрес «взломан» позволяет кому-либо войти на сайт ASP.net без имени пользователя / пароля.

Answer 3

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

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

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

UserId + [Value representing current time to nearest x minute / hour /day] + Salt

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

В общем, я думаю, что предложенное вами решение соответствует проблеме. Это, конечно, не слишком сложно.

Answer 4

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

В качестве альтернативы вы можете заставить приложение ASP добавить cookie сеанса GUID после входа в систему и сохранить этот GUID в таблице БД. Ваш ASP.NET может найти GUID в файле cookie, чтобы узнать, был ли достигнут вход в систему. Если вы включите в таблицу значение cookie сеанса ASP, вы можете разумно убедиться, что текущий сеанс ASP совпадает с сеансом, использованным при создании GUID.

Answer 5

Не могли бы вы отправить его через форму, а не через строку запроса? Это исключило бы возможность его перехвата в URL.