2010-11-17 6 views
1

У кого-нибудь есть указатели для реализации:многофакторная аутентификация для asp.net

Я хочу недорого включить многофакторную аутентификацию на веб-сайте asp.net. Я хочу, чтобы люди могли использовать приложение на своем телефоне (по крайней мере, iPhone), чтобы генерировать токен, используемый вместе с их именем пользователя/паролем для входа на сайт.

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

спасибо, Эндрю

ответ

0

Мой подход был бы:

  • Каждый клиент получает копию открытого ключа
  • Каждый клиент получает случайный GUID, что он будет идентифицирован с
  • A настраиваемый код, который генерирует токен, основанный на времени (до минуты), IP-адрес (возможно) и GUID с помощью ключа.

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

Затем, для использования сайта, токен генерируется и шифруется ключом и отправляется на сервер. Сервер дизассемблирует токен и идентифицирует GUID и соответствует времени и IP-адресу (возможно).

0

Несколько факторов просто означают более одного способа проверки личности пользователя. Идентификатор имени пользователя/входа - это идентификатор, поэтому нам нужно убедиться, что идентификатор действительно исходит от человека, которому он назначен.

Самый распространенный (и самый расстраивающий) способ проверки - это пароль. Это секрет, который якобы знает только пользователь.

Другие формы проверки включают в себя:

  • Mac идентификатор адреса/машина (если она исходит от известного источника, это, вероятно, они - к сожалению, легко подделать, а).
  • PKI - ключевое управление - это единственное, что делает его более безопасным, чем пароль. По сути дела, вы должны проверить, что запрос сертификата, который они отправляют с их устройства, действительно им. Как только вы это сделаете, вы выдаете сертификат, который они используют с этой точки вперед. ПРИМЕЧАНИЕ. Не все браузеры поддерживают PKI (в настоящий момент это заметный недостаток в Google Chrome).
  • Вторичный общий секрет. Это может быть GUID, который обменивается через зашифрованное соединение или что-то в этом роде.
  • Биометрические данные. Требуется внешнее оборудование, но отпечатки пальцев и сканирование сетчатки могут быть трудно реплицироваться.
  • Мутирующий ключ с внешнего сервиса. Что-то вроде фрейма RSA, который каждую минуту отображает новый шестизначный ключ. Комбинация серийного номера fob и отображаемой клавиши гарантирует, что у вас есть правильный парень.

ПРИМЕЧАНИЕ: USB-устройство RSA является внешним устройством, но вы вызываете и не требуете подключения к клиентской машине. После того как вы связали серийный номер fob с учетной записью, вы используете шестизначный ключ пользователя в службе аутентификации RSA. Конечно, время сервера необходимо синхронизировать с RSA.Многие корпоративные VPN используют это как вторичный (или иногда первичный) метод проверки пользователя.

Я уверен, что есть много других вариантов. Трюк заключается в нахождении правильного баланса между требуемой безопасностью и головной болью обслуживания, когда метод проверки не работает, и пользователь требует поддержки.

Смежные вопросы