Аутентификация веб-сервиса наподобие SecurID

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

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

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

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

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

Мысли?


authentication c# one-time-password asp.net
person Adam Haile    schedule 30.08.2013    source источник
comment
Я думаю, что мой старый токен RSA, когда это произойдет, просто запросит следующий ключ в качестве подтверждения.   -  person Garrison Neely    schedule 31.08.2013
comment
почему бы не изменить секретный ключ после, скажем, 10 обращений в службу поддержки?!   -  person Milad Hosseinpanahi    schedule 31.08.2013

Ответы (2)


arrow_upward
0
arrow_downward

Вы, очевидно, защищаете службу с помощью HTTPS, это будет шаг 1.

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

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

person Bart Czernicki    schedule 30.08.2013
comment
Да... забыл упомянуть, но да, HTTPS. Прохладный. Все звучит хорошо. Спасибо! - person Adam Haile; 31.08.2013

arrow_upward
0
arrow_downward

То, что вы описываете (SecureID RSA), основано на алгоритме TOTP.

Мало того, что проблема синхронизации, которую вы описываете, является проблемой, вы также должны иметь в виду, что не все часы работают с одинаковой скоростью. Часы клиента могут идти немного быстрее или медленнее, чем часы вашего сервера, и со временем они могут рассинхронизироваться на несколько минут. Алгоритм TOTP обрабатывает это (см. раздел 6 RFC): когда сервер проверяет код, который он получает от клиента, не только на текущий код времени, но также на несколько кодов в будущем и несколько кодов в прошлом.

                            Client       Server
                    Time    Code         Code   Time    Offset
                                   Match 849207 8:30:00 -0:00
                                         641239 8:30:30 -0:00
                                         761548 8:31:00 -0:00
Current client time 8:30:00 849207       103970 8:31:30 -0:00 Current server time
                                         846541 8:32:00 -0:00
                                         861321 8:32:30 -0:00
                                         132465 8:33:00 -0:00

Если сервер обнаруживает, что коды рассинхронизированы на определенную величину, он вычисляет смещение (на сколько времени рассинхронизировались часы), а затем учитывает это смещение в будущем.

                            Client       Server
                    Time    Code         Code   Time    Offset
                                         628484 8:45:00 -1:30
                                         137864 8:45:30 -1:30
                                         679913 8:46:00 -1:30
Current client time 8:45:00 264951 Match 264951 8:46:30 -1:30 Current server time
                                         971034 8:47:00 -1:30
                                         626378 8:47:30 -1:30
                                         599171 8:48:00 -1:30

Даже если часы продолжают расходиться, сервер просто повторно синхронизируется, увеличив смещение, когда коды слишком сильно рассинхронизируются.

Если вы продолжите это, я настоятельно рекомендую вам использовать библиотеку, совместимую с RFC. Большинство языков имеют реализации с открытым исходным кодом, которые относительно легко найти, что упростит интеграцию этой аутентификации для ваших потребителей. Существует несколько реализаций C#, эта утверждает, что работает с аутентификатором Google (который, как я знаю, совместим с TOTP RFC).

Примечание. Большинство библиотек TOTP не выполняют за вас процесс повторной синхронизации, поскольку вам необходимо сохранить смещение синхронизации. Это довольно просто создать самостоятельно, просто прочитайте соответствующие разделы RFC, чтобы полностью понять процесс.

P.S.

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

Системы, подобные TOTP, работают с общим секретным ключом (code=TOTP(key, time)). Это полезно для людей, потому что злоумышленники не могут украсть код или общий секрет без физического доступа к токену SecureID (или любой другой марки). Единственная атака — получить текущий код от пользователя и немедленно его использовать. Однако это неверно для межмашинной аутентификации, потому что клиентская машина должна иметь доступ к общему секрету для генерации кодов. Если администратор или злоумышленник может украсть статический пароль из клиентской системы, нет никаких причин, по которым они не могут вместо этого украсть общий секрет.

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

person Syon    schedule 30.08.2013