Мне очень нравится первый подход в целом.
- это просто понять и реализовать
- это безопасно (насколько мне известно)
- это не редкий подход, который я видел в прошлом
Одна вещь, о которой я не упомянул, касающаяся первой, которую вы должны иметь в виду, - отметка времени, используемая для хэширования токена, должна иметь срок действия TTL, который является чрезвычайно коротким (например, 1 секунда), поэтому вы проверяете, что сообщение не было отправлено с та же отметка времени и токен из сообщения 12 часами ранее; очевидно, что это будет считаться законным, но это не так.
Если это только два варианта, которые вы рассматриваете, хотя я просто хотел бы убедиться, что вы рассматривали и другие подходы, так как их много. Больше, чем я собираюсь перечислить на самом деле. Это некоторые общие аутентичные подходы, которые стоит изучить, просто чтобы посмотреть, могут ли они лучше соответствовать вашим целям, и если ничто иное, их понимание, может дать вам некоторые идеи, которые помогут усовершенствовать любой подход, к которому вы подходите.
Обратите внимание, я не эксперт по безопасности.
OAuth / Федеративные
При таком подходе у вас есть сторонний гарант, в котором потребительский код запрашивает токен / сертификат / что у вас от них и передает его вам, на данный момент все, что вам нужно сделать, - это спросить третье лицо, был ли вам дан ключ законны.
Pro:
- Стандарты на основе
- Проблемы будут обнаружены другими в системах других людей, так что вы узнаете, происходит ли отсутствие безопасности
- Вам понадобится гораздо меньше аутентичной работы
Против:
- Вы должны иметь дело со сторонним сервисером и его API, или создать и разместить свою собственную "стороннюю", чтобы отделить аутентификацию от вашего основного сервиса.
- Для многих услуг излишнее, но концептуально стоит задуматься
Асинхронные сертификаты
Здесь ваши клиенты будут шифровать свои сообщения с помощью общедоступного сертификата, которым вы поделились с ним при создании пользователя. На вашей стороне вы расшифруете, используя закрытый ключ, связанный с этим пользователем. Обычно вы начинаете общение с помощью запроса-ответа, чтобы показать, что они могут шифровать / дешифровать, как вы ожидаете, идентифицируя их как того, кем они себя называют. Хотя возможны «синхронные» подходы, которые не используют запрос-ответ, они имеют немного меньшую безопасность и некоторые проблемы синхронизации времени, которые могут сделать их более сложными.
от Novell (да, я знаю, новелл? правда?)
Токены используют переменную в качестве основы для генерации одноразового пароля. Эта переменная называется проблемой. Два основных метода определения переменной, используемой для генерации пароля, являются асинхронными или синхронными.
При использовании асинхронного метода или метода «запрос-ответ» серверное программное обеспечение отправляет токену внешний вызов - случайно сгенерированную переменную - для шифрования устройства токена. Токен использует эту переменную вызова, алгоритм шифрования и общий секрет для генерации ответа - правильно зашифрованный пароль.
При использовании синхронного метода переменная вызова, используемая для генерации пароля, определяется токеном и сервером. В качестве основы для переменной вызова используется счетчик времени, счетчик событий или комбинация счетчика времени и событий в каждом устройстве. Поскольку каждый токен и сервер по отдельности и внутри определяют переменную вызова по своим собственным счетчикам, очень важно, чтобы их счетчики времени и счетчики событий оставались синхронизированными. Поскольку сервер и токен так легко выходят из синхронизации, большинство реализаций допускают определенное смещение между счетчиками. Обычно для вычисления пароля используется небольшой диапазон или окно значений этих счетчиков. Однако, если токен и сервер не синхронизируются за пределами этого окна,
Pro:
- Сертификаты имеют корни CA, которые делают их надежными и трудно подделанными
- В операционных системах есть стандартные средства для легкого управления и обслуживания сертификатов.
- Хорошо проработанный подход, много информации на нем
- Истекают наряду со множеством других вещей встроенные средства стандартных сертификатов, они, как правило, надежны
Против:
- С сертификатами работать сложно программно
- В зависимости от того, требуется ли вам внешний центр сертификации, возможно, он не бесплатный
- Может потребоваться поддерживать хранилища сертификатов вручную, чтобы обеспечить настройку ожидаемых корневых отношений доверия
NTLM
Не смейтесь, если это небольшая или внутренняя служба и вы работаете в среде Windows, нет ничего плохого в использовании стандартной аутентификации NTLM для гарантии доступа. Особенно, если вы работаете с IIS, это самый простой подход. Легко поддерживать и настраивать также в web.config.
Pro:
- Чрезвычайно прост в настройке, внедрении и обслуживании
Против:
- Минимальная совместимость
- Недостаточно для публичной аутентификации
одноразовые
При работе с одноразовыми номерами в подходе аутентификации вы предоставляете метод для получения одноразовых номеров в службе. Этот метод возвращает уникальную произвольную строку или часть данных ("nonce") по каждому запросу. Каждый запрос к другим методам теперь требует получения одноразового номера и использования в алгоритме шифрования для запроса. Значение здесь в том, что сервер отслеживает использованные одноразовые номера и никогда не разрешает повторное использование одноразового номера, это полностью предотвращает повторные атаки, поскольку после выполнения запроса с одним одноразовым номером запрос с этим одноразовым номером больше никогда не может быть выполнен. Когда запрашиваются одноразовые номера, они добавляются в список доступных одноразовых номеров, а когда они используются, они перемещаются из доступного списка в используемый список.
Pro:
- Сильно неплохо переигрывает атаки
- Не совсем сложно реализовать или понять
Против:
- Требует, чтобы клиенты делали два запроса для каждого запроса (хотя могут быть уменьшены, если требуются одноразовые номера только для определенных запросов)
- Требуется управление одноразовыми номерами, которые должны быть транзакционными
- Отрицательно влияет на производительность, требуя дополнительных запросов для одноразовых номеров (транзакционность дополнительно увеличивает стоимость ресурсов для работы с одноразовыми номерами)