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

Question

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

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

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

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

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

Мысли?

Answer 1

Вы, очевидно, обеспечивая обслуживание с Https, который был бы шаг 1.

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

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

Answer 2

То, что вы описываете (RSA SecureID), основывается на TOTP algorithm.

Не только проблема синхронизации, которую вы описали, но и помните, что не все часы работают с одинаковой скоростью. Часы клиента могут работать немного быстрее или медленнее, чем часы вашего сервера, и со временем они могут быть деинхронизированы на несколько минут. Способ, которым алгоритм TOTP обрабатывает это (see section 6 of the 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#, this one утверждает, что работает с аутентификатором Google (который, как я знаю, совместим с TOTP RFC).

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

P.S.

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

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

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