Мы работаем над новым проектом, мы являемся двумя ведущими разработчиками и попали на перекресток о том, как использовать токен для защиты связи между сервером и клиентом.

Первое предложение: (Одноразовый токен AKA Static Token)

1. клиент запрашивает первичный токен, отправляя имя пользователя и пароль, а также current_time (эта переменная будет сохранена в базе данных сервера и на стороне клиента) в API, сервер интерпретирует ввод и отображает хешированный токен (например: 58f52c075aca5d3e07869598c4d66648) сохраняет его в базе данных и возвращает клиенту.

2. Теперь клиент сохраняет первичный токен и создает новый хешированный токен, используя первичный токен + переменную current_time, отправленную в запросе на аутентификацию (давайте вызовем этот новый токен, main_token), также сервер делает то же самое и создает тот же токен, используя тот же алгоритм ,

3. Каждый раз, когда клиент запрашивает серверный API, он отправляет main_token на сервер, теперь сервер сравнивает сгенерированный в нем токен с main_token, отправленным клиентом, если он совпадает, это означает, что пользователь настоящий

Второе предложение: (динамический токен)

1. Клиент генерирует два случайных ключа ($ key1 = rand (10000,90000); $ key2 = rand (10000,90000);) При каждом запросе к API клиент создает хеш с использованием типа запроса, и два ключа с сложный алгоритм, и отправляет эти два ключа + хэш на сервер

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

Теперь возникает вопрос: какой из них является наиболее логичным и безопасным способом защиты запросов API?

Мне очень нравится первый подход в целом.

• это просто понять и реализовать
• это безопасно (насколько мне известно)
• это не редкий подход, который я видел в прошлом

Одна вещь, о которой я не упомянул, касающаяся первой, которую вы должны иметь в виду, - отметка времени, используемая для хэширования токена, должна иметь срок действия TTL, который является чрезвычайно коротким (например, 1 секунда), поэтому вы проверяете, что сообщение не было отправлено с та же отметка времени и токен из сообщения 12 часами ранее; очевидно, что это будет считаться законным, но это не так.

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

Обратите внимание, я не эксперт по безопасности.

OAuth / Федеративные

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

Pro:

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

Против:

• Вы должны иметь дело со сторонним сервисером и его API, или создать и разместить свою собственную "стороннюю", чтобы отделить аутентификацию от вашего основного сервиса.
• Для многих услуг излишнее, но концептуально стоит задуматься

Асинхронные сертификаты

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

от Novell (да, я знаю, новелл? правда?)

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

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

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

Pro:

• Сертификаты имеют корни CA, которые делают их надежными и трудно подделанными
• В операционных системах есть стандартные средства для легкого управления и обслуживания сертификатов.
• Хорошо проработанный подход, много информации на нем
• Истекают наряду со множеством других вещей встроенные средства стандартных сертификатов, они, как правило, надежны

Против:

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

NTLM

Не смейтесь, если это небольшая или внутренняя служба и вы работаете в среде Windows, нет ничего плохого в использовании стандартной аутентификации NTLM для гарантии доступа. Особенно, если вы работаете с IIS, это самый простой подход. Легко поддерживать и настраивать также в web.config.

Pro:

• Чрезвычайно прост в настройке, внедрении и обслуживании

Против:

• Минимальная совместимость
• Недостаточно для публичной аутентификации

одноразовые

При работе с одноразовыми номерами в подходе аутентификации вы предоставляете метод для получения одноразовых номеров в службе. Этот метод возвращает уникальную произвольную строку или часть данных ("nonce") по каждому запросу. Каждый запрос к другим методам теперь требует получения одноразового номера и использования в алгоритме шифрования для запроса. Значение здесь в том, что сервер отслеживает использованные одноразовые номера и никогда не разрешает повторное использование одноразового номера, это полностью предотвращает повторные атаки, поскольку после выполнения запроса с одним одноразовым номером запрос с этим одноразовым номером больше никогда не может быть выполнен. Когда запрашиваются одноразовые номера, они добавляются в список доступных одноразовых номеров, а когда они используются, они перемещаются из доступного списка в используемый список.

Pro:

• Сильно неплохо переигрывает атаки
• Не совсем сложно реализовать или понять

Против:

• Требует, чтобы клиенты делали два запроса для каждого запроса (хотя могут быть уменьшены, если требуются одноразовые номера только для определенных запросов)
• Требуется управление одноразовыми номерами, которые должны быть транзакционными
• Отрицательно влияет на производительность, требуя дополнительных запросов для одноразовых номеров (транзакционность дополнительно увеличивает стоимость ресурсов для работы с одноразовыми номерами)