Авторизация компьютера для доступа к веб-приложению

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

Вариант использования

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

Нам требуется очень простое решение (то есть не требующее установки программного обеспечения на стороне клиента) и работающее с Safari, Chrome, Firefox и IE 7+ (к сожалению). Мы предложим безопасность x509, которая обеспечивает адекватную безопасность, но нам все еще нужно решение для клиентов, которые не могут или не хотят использовать x509.

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

На первый взгляд

Initial secure sign-on sequence diagram Отслеживайте два отдельных значения (локальные данные или файлы cookie): хэш, представляющий токен безопасного входа, а также токен устройства. Оба значения управляются (и записываются) веб-приложением и диктуются клиенту. Токен SSO зависит от устройства, а также от порядкового номера. Это эффективно позволяет деавторизовать устройства (все токены SSO становятся недействительными) и смягчает повторное воспроизведение (хотя и неэффективно, поэтому я задаю этот вопрос) за счет использования порядкового номера и использования одноразового номера.

Проблема

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

Мне кажется, лучше использовать HMAC. Отслеживайте устройство, последовательность, создавайте одноразовый номер, временную метку и хэш с помощью закрытого ключа, а затем отправьте хеш вместе с этими значениями в виде обычного текста.Сервер делает то же самое (помимо проверки устройства и последовательности) и сравнивает. Это кажется намного проще и намного надежнее... если предположить, что мы можем безопасно договариваться, обмениваться и хранить закрытые ключи.

Вопрос

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

9
задан mgrbsk 12 June 2012 в 03:59
поделиться